rfc9711v1.txt   rfc9711.txt 
Internet Engineering Task Force (IETF) L. Lundblade Internet Engineering Task Force (IETF) L. Lundblade
Request for Comments: 9711 Security Theory LLC Request for Comments: 9711 Security Theory LLC
Category: Standards Track G. Mandyam Category: Standards Track G. Mandyam
ISSN: 2070-1721 Mediatek USA ISSN: 2070-1721
J. O'Donoghue J. O'Donoghue
Qualcomm Technologies Inc. Qualcomm Technologies Inc.
C. Wallace C. Wallace
Red Hound Software, Inc. Red Hound Software, Inc.
January 2025 April 2025
The Entity Attestation Token (EAT) The Entity Attestation Token (EAT)
Abstract Abstract
An Entity Attestation Token (EAT) provides an attested claims set An Entity Attestation Token (EAT) provides an attested claims set
that describes the state and characteristics of an entity, a device that describes the state and characteristics of an entity, a device
such as a smartphone, an Internet of Things (IoT) device, network such as a smartphone, an Internet of Things (IoT) device, network
equipment, or such. This claims set is used by a relying party, equipment, or such. This claims set is used by a relying party,
server, or service to determine the type and degree of trust placed server, or service to determine the type and degree of trust placed
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.
A verifier confirms an EAT is valid by verifying the signature and A verifier confirms an EAT is valid by verifying the signature and
may vet some claims using reference values. The verifier then may vet some claims using reference values. The verifier then
produces attestation results, which may also be represented as an produces attestation results, which may also be represented as an
EAT. The attestation results are provided to the relying party, EAT. The attestation results are provided to the relying party,
which is the ultimate consumer of the RAT. The relying party uses which is the ultimate consumer of the Remote Attestation Procedure.
the attestation results as needed for its use case, perhaps allowing The relying party uses the attestation results as needed for its use
an entity to access a network, a financial transaction, or such. In case, perhaps allowing an entity to access a network, a financial
some cases, the verifier and relying party are not distinct entities. transaction, or such. In some cases, the verifier and relying party
are not distinct entities.
1.3.1. Relationship between Evidence and Attestation Results 1.3.1. Relationship between Evidence and Attestation Results
Any claim defined in this document or in the IANA "CBOR Web Token Any claim defined in this document or in the IANA "CBOR Web Token
(CWT) Claims" or "JSON Web Token Claims" registries may be used in (CWT) Claims" or "JSON Web Token Claims" registries may be used in
evidence or attestation results. The relationship of claims in evidence or attestation results. The relationship of claims in
attestation results to evidence is fundamentally governed by the attestation results to evidence is fundamentally governed by the
verifier and the verifier's policy. verifier and the verifier's policy.
A common use case is for the verifier and its policy to perform A common use case is for the verifier and its policy to perform
skipping to change at line 461 skipping to change at line 463
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: base64 encoding using the URL- and filename-safe
filename-safe character set [RFC4648] with all trailing '=' character set defined in Section 5 of [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 [RFC7515].
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
with cryptographic keys.) with cryptographic keys.)
Claim Value: The value portion of the claim. A claim value can be Claim Value: The value portion of the claim. A claim value can be
any CBOR data item or JSON value. any CBOR data item or JSON value.
Claims Set: The CBOR map or JSON object that contains the claims Claims Set: The CBOR map or JSON object that contains the claims
conveyed by the CWT or JWT. conveyed by the CWT or JWT.
This document reuses terminology from RATS Architecture [RFC9334]: This document reuses terminology from RATS Architecture [RFC9334];
note that EAT does not capitalize RATS terms like "evidence" for
easier readability:
Attester: A role performed by an entity (typically a device) whose Attester: A role performed by an entity (typically a device) whose
evidence must be appraised in order to infer the extent to which evidence must be appraised in order to infer the extent to which
the attester is considered trustworthy, such as when deciding the attester is considered trustworthy, such as when deciding
whether it is authorized to perform some operation. whether it is authorized to perform some operation.
Verifier: A role that appraises the validity of evidence about an Verifier: A role that appraises the validity of evidence about an
attester and produces attestation results to be used by a relying attester and produces attestation results to be used by a relying
party. party.
Relying Party: A role that depends on the validity of information Relying Party: A role performed by an entity that depends on the
about an attester for purposes of reliably applying application- validity of information about an attester for purposes of reliably
specific actions. For comparison, see "relying party" in applying application-specific actions. Compare: relying party
[RFC4949]. [RFC4949].
Evidence: A set of claims generated by an attester to be appraised Evidence: A set of claims generated by an attester to be appraised
by a verifier. Evidence may include configuration data, by a verifier. Evidence may include configuration data,
measurements, telemetry, or inferences. measurements, telemetry, or inferences.
Attestation Results: The output generated by a verifier, typically Attestation Results: The output generated by a verifier, typically
including information about an attester, where the verifier including information about an attester, where the verifier
vouches for the validity of the results. vouches for the validity of the results.
Reference Values: A set of values against which values of claims can Reference Values: A set of values against which values of claims can
be compared as part of applying an appraisal policy for evidence. be compared as part of applying an appraisal policy for evidence.
Reference values are sometimes referred to in other documents as Reference values are sometimes referred to in other documents as
"known-good values", "golden measurements", or "nominal values", "known-good values", "golden measurements", or "nominal values".
although those terms typically assume comparison for equality These terms typically assume comparison for equality, whereas
whereas reference values in this document might be more general here, reference values might be more general and be used in any
and used in any sort of comparison. sort of comparison.
Endorsement: A secure statement that an endorser vouches for the Endorsement: A secure statement that an endorser vouches for the
integrity of an attester's various capabilities such as claims integrity of an attester's various capabilities such as claims
collection and evidence signing. collection and evidence signing.
This document reuses terminology from CDDL [RFC8610]: This document reuses terminology from CDDL [RFC8610]:
Group Socket: The mechanism by which a CDDL definition is extended, Group Socket: The mechanism by which a CDDL definition is extended,
as described in [RFC8610] and [RFC9165]. as described in [RFC8610] and [RFC9165].
skipping to change at line 548 skipping to change at line 552
on the protocol carrying the EAT. In some cases, it may be by media on the protocol carrying the EAT. In some cases, it may be by media
type (e.g., in an HTTP Content-Type field). In other cases, it may type (e.g., in an HTTP Content-Type field). In other cases, it may
be through use of CBOR tags. There is no fixed mechanism across all be through use of CBOR tags. There is no fixed mechanism across all
use cases. use cases.
This document also defines another message, the detached EAT bundle This document also defines another message, the detached EAT bundle
(see Section 5), which holds a collection of detached claims sets and (see Section 5), which holds a collection of detached claims sets and
an EAT that provides integrity and authenticity protection for them. an EAT that provides integrity and authenticity protection for them.
Detached EAT bundles can be either CBOR or JSON encoded. Detached EAT bundles can be either CBOR or JSON encoded.
The following CDDL defines the top-level $EAT-CBOR-Tagged-Token, The following CDDL defines the top-level $CBOR-Tagged-Token, $EAT-
$EAT-CBOR-Untagged-Token, and $EAT-JSON-Token-Formats sockets (see CBOR-Untagged-Token, and $EAT-JSON-Token-Formats sockets (see
Section 3.9 of [RFC8610]), enabling future token formats to be Section 3.9 of [RFC8610]), enabling future token formats to be
defined. Any new format that plugs into one or more of these sockets defined. Any new format that plugs into one or more of these sockets
MUST be defined by an IETF Standards Action [RFC8126]. Of particular MUST be defined by an IETF Standards Action [RFC8126]. Of particular
use may be a token type that provides no direct authenticity or use may be a token type that provides no direct authenticity or
integrity protection for use with transport mechanisms that do integrity protection for use with transport mechanisms that do
provide the necessary security services [UCCS]. provide the necessary security services [UCCS].
Nesting of EATs is allowed and defined in Section 4.2.18.3. This Nesting of EATs is allowed and defined in Section 4.2.18.3. This
includes the nesting of an EAT that is in a different format than the includes the nesting of an EAT that is in a different format than the
enclosing EAT, i.e., the nested EAT may be encoded using CBOR and the enclosing EAT, i.e., the nested EAT may be encoded using CBOR and the
skipping to change at line 571 skipping to change at line 575
Nested-Token references the CDDL defined in this section. When new Nested-Token references the CDDL defined in this section. When new
token formats are defined, the means for identification in a nested token formats are defined, the means for identification in a nested
token MUST also be defined. token MUST also be defined.
The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and
for JSON-encoded EATs is EAT-JSON-Token (while CDDL and CDDL tools for JSON-encoded EATs is EAT-JSON-Token (while CDDL and CDDL tools
provide enough support for shared definitions of most items in this provide enough support for shared definitions of most items in this
document, they do not provide enough support for this sharing at the document, they do not provide enough support for this sharing at the
top level). top level).
EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token EAT-CBOR-Token = $CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
$EAT-CBOR-Tagged-Token /= CWT-Tagged-Message $CBOR-Tagged-Token /= CWT-Tagged-Message
$EAT-CBOR-Tagged-Token /= BUNDLE-Tagged-Message $CBOR-Tagged-Token /= BUNDLE-Tagged-Message
$EAT-CBOR-Untagged-Token /= CWT-Untagged-Message $EAT-CBOR-Untagged-Token /= CWT-Untagged-Message
$EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message $EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message
EAT-JSON-Token = $EAT-JSON-Token-Formats EAT-JSON-Token = $EAT-JSON-Token-Formats
$EAT-JSON-Token-Formats /= JWT-Message $EAT-JSON-Token-Formats /= JWT-Message
$EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message $EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message
4. The Claims 4. The Claims
skipping to change at line 618 skipping to change at line 622
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 provides a CDDL definition for most of the
defined in [RFC8392]. Similarly, this specification includes CDDL elements defined 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 In JSON, an EAT nonce is either a text string or an array of text
text strings. The array option supports multistage EAT verification strings. In CBOR, an EAT nonce is either a byte string or an array
and consumption. of byte strings. The array option supports multistage EAT
verification and consumption.
A claim named "nonce" was defined for JWT and registered with IANA in A claim named "nonce" was defined for JWT and registered with IANA in
the "JSON Web Token Claims" registry, but it MUST NOT be used because the "JSON Web Token Claims" registry, but it MUST NOT be used because
it does not support multiple nonces. No previous "nonce" claim was it does not support multiple nonces. No previous "nonce" claim was
defined for CWT. To distinguish from the previously defined JWT defined for CWT. To distinguish from the previously defined JWT
"nonce" claim, this claim is named "eat_nonce" in JSON-encoded EATs. "nonce" claim, this claim is named "eat_nonce" in JSON-encoded EATs.
The CWT nonce defined here is intended for general purpose use and The CWT nonce defined here is intended for general purpose use and
retains the "Nonce" claim name instead of an EAT-specific name. retains the "Nonce" claim name instead of an EAT-specific name.
An EAT nonce MUST have at least 64 bits of entropy. A maximum EAT An EAT nonce MUST have at least 64 bits of entropy. A maximum EAT
skipping to change at line 725 skipping to change at line 729
does not require registration fees and central administration. does not require registration fees and central administration.
In the unlikely event that a new UEID type is needed, it MUST be In the unlikely event that a new UEID type is needed, it MUST be
defined in an update to this document on the Standards Track. defined in an update to this document on the Standards Track.
A manufacturer of entities MAY use different types for different A manufacturer of entities MAY use different types for different
products. They MAY also change from one type to another for a given products. They MAY also change from one type to another for a given
product or use one type for some items of a given product and another product or use one type for some items of a given product and another
type for others. type for others.
+======+======+=====================================================+ +======+======+====================================================+
| Type | Type | Specification | | Type | Type | Specification |
| Byte | Name | | | Byte | Name | |
+======+======+=====================================================+ +======+======+====================================================+
| 0x01 | RAND | This is a 128-, 192-, or 256-bit random number | | 0x01 | RAND | This is a 128-, 192-, or 256-bit random number |
| | | generated once and stored in the entity. This | | | | generated once and stored in the entity. This may |
| | | may be constructed by concatenating enough | | | | be constructed by concatenating enough identifiers |
| | | identifiers to make up an equivalent number of | | | | to make up an equivalent number of random bits and |
| | | random bits and then feeding the concatenation | | | | then feeding the concatenation through a |
| | | through a cryptographic hash function. It may | | | | cryptographic hash function. It may also be a |
| | | also be a cryptographic quality random number | | | | cryptographic quality random number generated once |
| | | generated once at the beginning of the life of | | | | at the beginning of the life of the entity and |
| | | the entity and stored. It MUST NOT be smaller | | | | stored. It MUST NOT be smaller than 128 bits. |
| | | than 128 bits. See the length analysis in | | | | See the length analysis in Appendix B. |
| | | Appendix B. | +------+------+----------------------------------------------------+
+------+------+-----------------------------------------------------+ | 0x02 | IEEE | This makes use of the device identification scheme |
| 0x02 | IEEE | This makes use of the device identification | | | EUI | operated by the IEEE. An Extended Unique |
| | EUI | scheme operated by the IEEE. An Extended Unique | | | | Identifier (EUI) can be an EUI-48, EUI-60, or |
| | | Identifier (EUI) is either an EUI-48, EUI-60, or | | | | EUI-64 and consists of two parts. The first part |
| | | EUI-64 that is made up of an Organizationally | | | | is a registered company identifier, an |
| | | Unique Identifier (OUI), an OUI-36, or a Company | | | | Organizationally Unique Identifier (OUI), an OUI- |
| | | ID (CID), which are different registered company | | | | 36, or a Company ID (CID). The second part |
| | | identifiers and some unique per-entity | | | | ensures uniqueness within the registered company. |
| | | identifiers. EUIs are often the same as or | | | | EUIs are often the same as or similar to MAC |
| | | similar to MAC addresses. This type includes | | | | addresses. This type includes MAC-48, an obsolete |
| | | MAC-48, an obsolete name for EUI-48. (Note that | | | | name for EUI-48. (Note that while entities with |
| | | while entities with multiple network interfaces | | | | multiple network interfaces may have multiple MAC |
| | | may have multiple MAC addresses, there is only | | | | addresses, there is only one UEID for an entity; |
| | | one UEID for an entity; changeable MAC addresses | | | | changeable MAC addresses that do not meet the |
| | | that do not meet the permanence requirements in | | | | permanence requirements in this document MUST NOT |
| | | this document MUST NOT be used for the UEID or | | | | be used for the UEID or Semipermanent UEID |
| | | Semi-permanent UEID (SUEID).) See | | | | (SUEID).) See [IEEE.802-2014] and [OUI.Guide]. |
| | | [IEEE.802-2001] and [OUI.Guide]. | +------+------+----------------------------------------------------+
+------+------+-----------------------------------------------------+ | 0x03 | IMEI | This makes use of the International Mobile |
| 0x03 | IMEI | This makes use of the International Mobile | | | | Equipment Identity (IMEI) scheme operated by the |
| | | Equipment Identity (IMEI) scheme operated by the | | | | Global System for Mobile Communications |
| | | Global System for Mobile Communications | | | | Association (GSMA). This is a 14-digit identifier |
| | | Association (GSMA). This is a 14-digit | | | | consisting of an 8-digit Type Allocation Code |
| | | identifier consisting of an 8-digit Type | | | | (TAC) and a 6-digit serial number allocated by the |
| | | Allocation Code (TAC) and a 6-digit serial | | | | manufacturer, which SHALL be encoded as a byte |
| | | number allocated by the manufacturer, which | | | | string of length 14 with each byte as the digit's |
| | | SHALL be encoded as a byte string of length 14 | | | | value (not the ASCII encoding of the digit; the |
| | | with each byte as the digit's value (not the | | | | digit 3 encodes as 0x03, not 0x33). The IMEI |
| | | ASCII encoding of the digit; the digit 3 encodes | | | | encoded value SHALL NOT include the Luhn checksum |
| | | as 0x03, not 0x33). The IMEI encoded value | | | | or Software Version Number (SVN) information. See |
| | | SHALL NOT include the Luhn checksum or Software | | | | [ThreeGPP.IMEI]. |
| | | Version Number (SVN) information. See | +------+------+----------------------------------------------------+
| | | [ThreeGPP.IMEI]. |
+------+------+-----------------------------------------------------+
Table 1: UEID Composition Types Table 1: UEID Composition Types
4.2.1.2. Rules for Consuming UEIDs 4.2.1.2. Rules for Consuming UEIDs
For the consumer, a UEID is solely a globally unique opaque For the consumer, a UEID is solely a globally unique opaque
identifier. The consumer does not and should not have any awareness identifier. The consumer does not and should not have any awareness
of the rules and structure used to achieve global uniqueness. of the rules and structure used to achieve global uniqueness.
All implementations MUST be able to receive UEIDs up to 33 bytes All implementations MUST be able to receive UEIDs up to 33 bytes
long. 33 bytes is the longest defined in this document and gives long. 33 bytes is the longest defined in this document and gives
necessary entropy for probabilistic uniqueness. necessary entropy for probabilistic uniqueness.
skipping to change at line 806 skipping to change at line 808
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 886
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]. When this claim is encoded, the order
format. When this claim is encoded, the order of bytes in the bstr of bytes in the bstr is the same as the order in the "hexadecimal
is the same as the order in the hexadecimal representation. For representation". For example, an MA-L like "AC-DE-48" would be
example, an MA-L like "AC-DE-48" would be encoded in 3 bytes with encoded in 3 bytes with values 0xAC, 0xDE, and 0x48.
values 0xAC, 0xDE, and 0x48.
This format is always 3 bytes in size in CBOR. This format is always 3 bytes in size in CBOR.
In JSON-encoded tokens, this MUST be base64url encoded and always 4 In JSON-encoded tokens, this MUST be base64url encoded and always 4
bytes. bytes.
4.2.3.3. IANA Private Enterprise Number-Based OEM ID 4.2.3.3. IANA Private Enterprise Number-Based OEM ID
IANA maintains a registry for Private Enterprise Numbers [PEN]. A IANA maintains a registry for Private Enterprise Numbers [PEN]. A
PEN is an integer that identifies an enterprise, and it may be used PEN is an integer that identifies an enterprise, and it may be used
skipping to change at line 920 skipping to change at line 921
arc that is managed by IANA: iso(1) identified-organization(3) dod(6) arc that is managed by IANA: iso(1) identified-organization(3) dod(6)
internet(1) private(4) enterprise(1). internet(1) private(4) enterprise(1).
For EAT purposes, only the integer value assigned by IANA as the PEN For EAT purposes, only the integer value assigned by IANA as the PEN
is relevant, not the full OID value. is relevant, not the full OID value.
In CBOR, this value MUST be encoded as a major type 0 integer and is 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. typically 3 bytes. In JSON, this value MUST be encoded as a number.
$$Claims-Set-Claims //= ( $$Claims-Set-Claims //= (
oemid-label => oemid-pen / oemid-ieee / oemid-random oemid-label => oemid-type
) )
oemid-type => oemid-pen / oemid-ieee / oemid-random
oemid-pen = int oemid-pen = int
oemid-ieee = JC<oemid-ieee-json, oemid-ieee-cbor> oemid-ieee = JC<oemid-ieee-json, oemid-ieee-cbor>
oemid-ieee-cbor = bstr .size 3 oemid-ieee-cbor = bstr .size 3
oemid-ieee-json = base64-url-text .size 4 oemid-ieee-json = base64-url-text .size 4
oemid-random = JC<oemid-random-json, oemid-random-cbor> oemid-random = JC<oemid-random-json, oemid-random-cbor>
oemid-random-cbor = bstr .size 16 oemid-random-cbor = bstr .size 16
oemid-random-json = base64-url-text .size 24 oemid-random-json = base64-url-text .size 24
skipping to change at line 1136 skipping to change at line 1139
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 1278
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 1335
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 1362
] ]
$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 1411
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 1437
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 1498 skipping to change at line 1500
The Submodule type and Nested-Token type definitions vary with the The Submodule type and Nested-Token type definitions vary with the
type of encoding. The definitions for CBOR-encoded EATs are as type of encoding. The definitions for CBOR-encoded EATs are as
follows: follows:
Nested-Token = CBOR-Nested-Token Nested-Token = CBOR-Nested-Token
CBOR-Nested-Token = CBOR-Nested-Token =
JSON-Token-Inside-CBOR-Token / JSON-Token-Inside-CBOR-Token /
CBOR-Token-Inside-CBOR-Token CBOR-Token-Inside-CBOR-Token
CBOR-Token-Inside-CBOR-Token = bstr .cbor $EAT-CBOR-Tagged-Token CBOR-Token-Inside-CBOR-Token = bstr .cbor $CBOR-Tagged-Token
JSON-Token-Inside-CBOR-Token = tstr JSON-Token-Inside-CBOR-Token = tstr
$$Claims-Set-Claims //= (submods-label => { + text => Submodule }) $$Claims-Set-Claims //= (submods-label => { + text => Submodule })
Submodule = Claims-Set / CBOR-Nested-Token / Submodule = Claims-Set / CBOR-Nested-Token /
Detached-Submodule-Digest Detached-Submodule-Digest
The Submodule and Nested-Token definitions for JSON-encoded EATs are The Submodule and Nested-Token definitions for JSON-encoded EATs are
as below. The definitions are necessarily different than CBOR as below. The definitions are necessarily different than CBOR
skipping to change at line 1537 skipping to change at line 1539
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
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
"JWT", "CBOR", "BUNDLE", or future-standardized token types, e.g., "JWT", "CBOR", "BUNDLE", or future-standardized token types, e.g.,
see [UCCS], the submodule is a nested token of the indicated type, see [UCCS], the submodule is a nested token of the indicated type,
i.e., JWT-Message, CBOR-Token-Inside-JSON-Token, Detached-EAT-Bundle, i.e., JWT-Message, CBOR-Token-Inside-JSON-Token, Detached-EAT-Bundle,
skipping to change at line 1583 skipping to change at line 1585
"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 1766 skipping to change at line 1767
EAT bundle, they can be very short, perhaps one byte. EAT bundle, they can be very short, perhaps one byte.
BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message
BUNDLE-Tagged-Message = #6.602(BUNDLE-Untagged-Message) BUNDLE-Tagged-Message = #6.602(BUNDLE-Untagged-Message)
BUNDLE-Untagged-Message = Detached-EAT-Bundle BUNDLE-Untagged-Message = Detached-EAT-Bundle
Detached-EAT-Bundle = [ Detached-EAT-Bundle = [
main-token : Nested-Token, main-token : Nested-Token,
detached-claims-sets: { detached-claims-sets: {
+ tstr => JC-NEST-SAFE<json-wrapped-claims-set, + tstr => JC<json-wrapped-claims-set,
cbor-wrapped-claims-set> cbor-wrapped-claims-set>
} }
] ]
json-wrapped-claims-set = base64-url-text json-wrapped-claims-set = base64-url-text
cbor-wrapped-claims-set = bstr .cbor Claims-Set cbor-wrapped-claims-set = bstr .cbor Claims-Set
6. Profiles 6. Profiles
EAT makes normative use of CBOR, JSON, COSE, JOSE, CWT, and JWT. EAT makes normative use of CBOR, JSON, COSE, JOSE, CWT, and JWT.
skipping to change at line 1812 skipping to change at line 1813
guarantee interoperability. EAT chooses one general and explicit guarantee interoperability. EAT chooses one general and explicit
mechanism, the profile, to indicate the choices made for these mechanism, the profile, to indicate the choices made for these
implementation options for all aspects of the token. implementation options for all aspects of the token.
Below is a list of the various issues that should be addressed by a Below is a list of the various issues that should be addressed by a
profile. profile.
The "eat_profile" claim in Section 4.3.2 provides a unique identifier The "eat_profile" claim in Section 4.3.2 provides a unique identifier
for the profile a particular token uses. for the profile a particular token uses.
A profile can apply to evidence results, attestation results, or A profile can apply to evidence, attestation results, or both.
both.
6.1. Format of a Profile Document 6.1. Format of a Profile Document
A profile document does not have to be in any particular format. It A profile document does not have to be in any particular format. It
may be simple text, something more formal, or a combination of both. may be simple text, something more formal, or a combination of both.
A profile may define, and possibly register, one or more new claims A profile may define, and possibly register, one or more new claims
if needed. A profile may also reuse one or more already defined if needed. A profile may also reuse one or more already defined
claims either as is or with values constrained to a subset or claims either as is or with values constrained to a subset or
subrange. subrange.
skipping to change at line 1910 skipping to change at line 1910
must be sent or not. A profile should specify that the receiver must be sent or not. A profile should specify that the receiver
accepts preferred and/or non-preferred serialization, so it will be accepts preferred and/or non-preferred serialization, so it will be
able to accept anything sent by the sender. able to accept anything sent by the sender.
6.3.5. CBOR Tags 6.3.5. CBOR Tags
The profile should specify whether the token should be a CWT tag or The profile should specify whether the token should be a CWT tag or
not. not.
When COSE protection is used, the profile should specify whether COSE When COSE protection is used, the profile should specify whether COSE
tags are used or not. Note that RFC 8392 requires COSE tags be used tags are used or not. Note that [RFC8392] requires COSE tags be used
in a CWT tag. in a CWT tag.
Often, a tag is unnecessary because the surrounding or carrying Often, a tag is unnecessary because the surrounding or carrying
protocol identifies the object as an EAT. protocol identifies the object as an EAT.
6.3.6. COSE/JOSE Protection 6.3.6. COSE/JOSE Protection
COSE and JOSE have several options for signed, MACed, and encrypted COSE and JOSE have several options for signed, MACed, and encrypted
messages. JWT may use the JOSE NULL protection option. It is messages. It may be an Unsecured JWT as described in Section 6 of
possible to implement no protection, sign only, MAC only, sign then [RFC7519]. It is possible to implement no protection, sign only, MAC
encrypt, and so on. All combinations allowed by COSE, JOSE, JWT, and only, sign then encrypt, and so on. All combinations allowed by
CWT are allowed by EAT. COSE, JOSE, JWT, and CWT are allowed by EAT.
A profile should specify all signing, encryption, and MAC message A profile should specify all signing, encryption, and MAC message
formats that may be sent. For example, a profile might allow only formats that may be sent. For example, a profile might allow only
COSE_Sign1 to be sent. As another example, a profile might allow COSE_Sign1 to be sent. As another example, a profile might allow
COSE_Sign and COSE_Encrypt to be sent to carry multiple signatures COSE_Sign and COSE_Encrypt to be sent to carry multiple signatures
for post quantum cryptography and to use encryption to provide for post quantum cryptography and to use encryption to provide
confidentiality. confidentiality.
A profile should specify that the receiver accepts all message A profile should specify that the receiver accepts all message
formats that are allowed to be sent. formats that are allowed to be sent.
skipping to change at line 2024 skipping to change at line 2024
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. A profile might require
requires the receiver to accept all variations that are allowed to be the receiver to accept all variations that are allowed to be sent.
sent.
6.4. The Constrained Device Standard Profile 6.4. The Constrained Device Standard Profile
It is anticipated that there will be many profiles defined for EAT It is anticipated that there will be many profiles defined for EAT
for many different use cases. This section gives a normative for many different use cases. This section gives a normative
definition of one profile that is good for many constrained device definition of one profile that is good for many constrained device
use cases. use cases.
The identifier for this profile is "urn:ietf:rfc:rfc9711". The identifier for this profile is "urn:ietf:rfc:rfc9711".
skipping to change at line 2140 skipping to change at line 2139
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 2212 skipping to change at line 2211
tokens. When this is the case, the JC<> CDDL construct is used to tokens. When this is the case, the JC<> CDDL construct is used to
give both the integer and string values. give both the integer and string values.
7.2.4. CBOR Interoperability 7.2.4. CBOR Interoperability
CBOR allows data items to be serialized in more than one form to CBOR allows data items to be serialized in more than one form to
accommodate a variety of use cases. This is addressed in Section 6. accommodate a variety of use cases. This is addressed in Section 6.
7.3. Collected CDDL 7.3. Collected CDDL
See [EAT-GitHub] for additional information and stub files, when
using the CDDL presented in this section to validate EAT protocol
messages.
7.3.1. Payload CDDL 7.3.1. Payload CDDL
The payload CDDL defines all the EAT claims that are added to the The payload CDDL defines all the EAT claims that are added to the
main definition of a Claims-Set in Appendix D. Claims-Set is the main definition of a Claims-Set in Appendix D. Claims-Set is the
payload for CWT, JWT, and potentially other token types. This is for payload for CWT, JWT, and potentially other token types. This is for
both CBOR and JSON. When there is variation between CBOR and JSON, both CBOR and JSON. When there is variation between CBOR and JSON,
the JC<> CDDL generic defined in Appendix D. 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 2407
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
BUNDLE-Tagged-Message = #6.602(BUNDLE-Untagged-Message) BUNDLE-Tagged-Message = #6.602(BUNDLE-Untagged-Message)
BUNDLE-Untagged-Message = Detached-EAT-Bundle BUNDLE-Untagged-Message = Detached-EAT-Bundle
Detached-EAT-Bundle = [ Detached-EAT-Bundle = [
main-token : Nested-Token, main-token : Nested-Token,
detached-claims-sets: { detached-claims-sets: {
+ tstr => JC-NEST-SAFE<json-wrapped-claims-set, + tstr => JC<json-wrapped-claims-set,
cbor-wrapped-claims-set> cbor-wrapped-claims-set>
} }
] ]
json-wrapped-claims-set = base64-url-text json-wrapped-claims-set = base64-url-text
cbor-wrapped-claims-set = bstr .cbor Claims-Set cbor-wrapped-claims-set = bstr .cbor Claims-Set
nonce-label = JC< "eat_nonce", 10 > nonce-label = JC< "eat_nonce", 10 >
ueid-label = JC< "ueid", 256 > ueid-label = JC< "ueid", 256 >
sueids-label = JC< "sueids", 257 > sueids-label = JC< "sueids", 257 >
skipping to change at line 2460 skipping to change at line 2463
dloas-label = JC< "dloas", 269 > dloas-label = JC< "dloas", 269 >
sw-name-label = JC< "swname", 270 > sw-name-label = JC< "swname", 270 >
sw-version-label = JC< "swversion", 271 > sw-version-label = JC< "swversion", 271 >
manifests-label = JC< "manifests", 272 > manifests-label = JC< "manifests", 272 >
measurements-label = JC< "measurements", 273 > measurements-label = JC< "measurements", 273 >
measurement-results-label = JC< "measres" , 274 > measurement-results-label = JC< "measres" , 274 >
intended-use-label = JC< "intuse", 275 > intended-use-label = JC< "intuse", 275 >
7.3.2. CBOR-Specific CDDL 7.3.2. CBOR-Specific CDDL
EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token EAT-CBOR-Token = $CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
$EAT-CBOR-Tagged-Token /= CWT-Tagged-Message $CBOR-Tagged-Token /= CWT-Tagged-Message
$EAT-CBOR-Tagged-Token /= BUNDLE-Tagged-Message $CBOR-Tagged-Token /= BUNDLE-Tagged-Message
$EAT-CBOR-Untagged-Token /= CWT-Untagged-Message $EAT-CBOR-Untagged-Token /= CWT-Untagged-Message
$EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message $EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message
Nested-Token = CBOR-Nested-Token Nested-Token = CBOR-Nested-Token
CBOR-Nested-Token = CBOR-Nested-Token =
JSON-Token-Inside-CBOR-Token / JSON-Token-Inside-CBOR-Token /
CBOR-Token-Inside-CBOR-Token CBOR-Token-Inside-CBOR-Token
CBOR-Token-Inside-CBOR-Token = bstr .cbor $EAT-CBOR-Tagged-Token CBOR-Token-Inside-CBOR-Token = bstr .cbor $CBOR-Tagged-Token
JSON-Token-Inside-CBOR-Token = tstr JSON-Token-Inside-CBOR-Token = tstr
$$Claims-Set-Claims //= (submods-label => { + text => Submodule }) $$Claims-Set-Claims //= (submods-label => { + text => Submodule })
Submodule = Claims-Set / CBOR-Nested-Token / Submodule = Claims-Set / CBOR-Nested-Token /
Detached-Submodule-Digest Detached-Submodule-Digest
7.3.3. JSON-Specific CDDL 7.3.3. JSON-Specific CDDL
skipping to change at line 2608 skipping to change at line 2611
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 2744
"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
Claim Value Type: bstr or int Claim Value Type: bstr or int
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
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: bstr Claim Value Type: bstr
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
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: 260 Claim Key: 260
Claim Value Type: array Claim Value Type: array
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
Claim Name: Uptime Claim Name: Uptime
Claim Description: Uptime Claim Description: Uptime
JWT Claim Name: "uptime" JWT Claim Name: uptime
Claim Key: 261 Claim Key: 261
Claim Value Type: uint Claim Value Type: uint
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
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
Claim Value Type: map Claim Value Type: map
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
Claim Name: Boot Count Claim Name: Boot Count
Claim Description: The number of times the entity or submodule has Claim Description: The number of times the entity or submodule has
been booted been booted
JWT Claim Name: "bootcount" JWT Claim Name: bootcount
Claim Key: 267 Claim Key: 267
Claim Value Type: uint Claim Value Type: uint
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
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: 268 Claim Key: 268
Claim Value Type: bstr Claim Value Type: bstr
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
Claim Name: DLOAs Claim Name: DLOAs
Claim Description: Certifications received as Digital Letters of Claim Description: Certifications received as Digital Letters of
Approval Approval
JWT Claim Name: "dloas" JWT Claim Name: dloas
Claim Key: 269 Claim Key: 269
Claim Value Type: array Claim Value Type: array
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
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: 270 Claim Key: 270
Claim Value Type: tstr Claim Value Type: tstr
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
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: 271 Claim Key: 271
Claim Value Type: array Claim Value Type: array
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
Claim Name: Software Manifests Claim Name: Software Manifests
Claim Description: Manifests describing the software installed on Claim Description: Manifests describing the software installed on
the entity the entity
JWT Claim Name: "manifests" JWT Claim Name: manifests
Claim Key: 272 Claim Key: 272
Claim Value Type: array Claim Value Type: array
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
Claim Name: Measurements Claim Name: Measurements
Claim Description: Measurements of the software, memory Claim Description: Measurements of the software, memory
configuration, and such on the entity configuration, and such on the entity
JWT Claim Name: "measurements" JWT Claim Name: measurements
Claim Key: 273 Claim Key: 273
Claim Value Type: array Claim Value Type: array
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
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 2976
* 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. Description: This is one or more text paragraphs that
identify the use in JSON-encoded tokens.
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.
3. Reference: This field contains a reference to the defining
specification.
The following 5 values represent the initial content of the registry. The following 5 values represent the initial content of the registry.
Note that 0 will be marked as "reserved" for the CBOR value, and the Note that 0 will be marked as "reserved" for the CBOR value, and the
maximum CBOR value for assignment is 255. maximum CBOR value for assignment is 255.
1 -- Generic: Generic attestation describes an application where the 1 -- Generic: Generic attestation describes an application where the
EAT consumer requires the most up-to-date security assessment of EAT consumer requires the most up-to-date security assessment of
the attesting entity. It is expected that this is the most the attesting entity. It is expected that this is the most
commonly used application of EAT. commonly used application of EAT.
2 -- Registration: Entities that are registering for a new service 2 -- Registration: Entities that are registering for a new service
skipping to change at line 3046 skipping to change at line 3049
<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 3153
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,
<https://en.wikipedia.org/w/ <https://en.wikipedia.org/w/
index.php?title=Birthday_attack&oldid=1249270346>. index.php?title=Birthday_attack&oldid=1249270346>.
[CBOR.Certs] [CBOR.Certs]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
M. Furuhed, "CBOR Encoded X.509 Certificates (C509 M. Furuhed, "CBOR Encoded X.509 Certificates (C509
Certificates)", Work in Progress, Internet-Draft, draft- Certificates)", Work in Progress, Internet-Draft, draft-
ietf-cose-cbor-encoded-cert-12, 8 January 2025, ietf-cose-cbor-encoded-cert-13, 3 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose- <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-12>. cbor-encoded-cert-13>.
[CC-Example] [CC-Example]
Eurosmart, "Secure Sub-System in System-on-Chip (3S in Eurosmart, "Secure Sub-System in System-on-Chip (3S in
SoC) Protection Profile", Version 1.8, October 2023, SoC) Protection Profile", Version 1.8, October 2023,
<https://commoncriteriaportal.org/nfs/ccpfiles/files/ <https://commoncriteriaportal.org/nfs/ccpfiles/files/
ppfiles/pp0117V2b_pdf.pdf>. ppfiles/pp0117V2b_pdf.pdf>.
[EAT-GitHub]
"Entity Attestation Token IETF Draft Standard", commit
62c726b, January 2024,
<https://github.com/ietf-rats-wg/eat>.
[EAT.media-types] [EAT.media-types]
Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media
Types", Work in Progress, Internet-Draft, draft-ietf-rats- Types", Work in Progress, Internet-Draft, draft-ietf-rats-
eat-media-type-12, 3 November 2024, eat-media-type-12, 3 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats- <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
eat-media-type-12>. eat-media-type-12>.
[GP-Example] [GP-Example]
GlobalPlatform, "GlobalPlatform Technology: TEE GlobalPlatform, "GlobalPlatform Technology: TEE
Certification Process", Public Release Version 2.0, Certification Process", Public Release Version 2.0,
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 3267
[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 3397
} }
} }
} }
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 3453
/ 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 3631 skipping to change at line 3633
] ]
] ]
] ]
] ]
} }
A.1.7. JSON-Encoded Token with Submodules A.1.7. JSON-Encoded Token with Submodules
The lines in this example are wrapped per [RFC8792]. The lines in this example are wrapped per [RFC8792].
=============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"eat_nonce": "lI-IYNE6Rj6O", "eat_nonce": "lI-IYNE6Rj6O",
"ueid": "AJj1Ck_2wFhhyIYNE6Y46g==", "ueid": "AJj1Ck_2wFhhyIYNE6Y46g==",
"secboot": true, "secboot": true,
"dbgstat": "disabled-permanently", "dbgstat": "disabled-permanently",
"iat": 1526542894, "iat": 1526542894,
"submods": { "submods": {
"Android App Foo": { "Android App Foo": {
"swname": "Foo.app" "swname": "Foo.app"
}, },
skipping to change at line 3667 skipping to change at line 3671
} }
} }
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.3 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
AB233787' / signature / AB233787' / signature /
] ) ) ] ) )
A.2.2. CBOR-Encoded Detached EAT Bundle A.2.2. CBOR-Encoded Detached EAT Bundle
In this detached EAT bundle, the main token is produced by a hardware In this detached EAT bundle, the main token is produced by a hardware
(HW) attestation block. The detached Claims-Set is produced by a TEE (HW) attestation block. The detached Claims-Set is produced by a TEE
and is largely identical to the simple TEE examples above. The TEE and is largely identical to the simple TEE example in Appendix A.1.1.
digests its Claims-Set and feeds that digest to the HW block. The TEE digests its Claims-Set and feeds that digest to the HW block.
In a better example, the attestation produced by the HW block would In a better example, the attestation produced by the HW block would
be a CWT and thus signed and secured by the HW block. Since the be a CWT and thus signed and secured by the HW block. Since the
signature covers the digest from the TEE, that Claims-Set is also signature covers the digest from the TEE, that Claims-Set is also
secured. secured.
The detached EAT bundle itself can be assembled by untrusted The detached EAT bundle itself can be assembled by untrusted
software. software.
/ This is a detached EAT bundle tag. / / This is a detached EAT bundle tag. /
602([ 602([
/ The first part is a full EAT token with claims like nonce / / The first part is a full EAT token with claims like nonce /
/ and UEID. Most importantly, it includes a submodule that / / and UEID. Most importantly, it includes a submodule that /
/ is a detached digest, which is the hash of the "TEE" / / is a detached digest, which is the hash of the "TEE" /
/ claims set in the next section. The COSE payload is as / / claims set in the next part of the detached EAT bundle. /
/ follows: / / The COSE payload is as follows: /
/ { / / { /
/ 10: h'948F8860D13A463E', / / 10: h'948F8860D13A463E', /
/ 256: h'0198F50A4FF6C05861C8860D13A638EA', / / 256: h'0198F50A4FF6C05861C8860D13A638EA', /
/ 258: 64242, / / 258: 64242, /
/ 262: true, / / 262: true, /
/ 263: 3, / / 263: 3, /
/ 260: ["3.1", 1], / / 260: ["3.1", 1], /
/ 266: { / / 266: { /
/ "TEE": [ / / "TEE": [ /
/ -16, / / -16, /
/ h'8DEF652F47000710D9F466A4C666E209 / / h'ab86f765643aabfd09c84eebe150b7f6 /
/ DD74F927A1CEA352B03143E188838ABE' / / 1bc24804cee75e90c5f99cb850fe808f' /
/ ] / / ] /
/ } / / } /
/ } / / } /
h'D83DD28443A10126A05866A80A48948F8860D13A463E1901 h'D83DD28443A10126A05866A80A48948F8860D13A463E1901
00500198F50A4FF6C05861C8860D13A638EA19010219FAF2 00500198F50A4FF6C05861C8860D13A638EA19010219FAF2
19010504190106F5190107031901048263332E310119010A 19010504190106F5190107031901048263332E310119010A
A163544545822F58208DEF652F47000710D9F466A4C666E2 A163544545822F58208DEF652F47000710D9F466A4C666E2
09DD74F927A1CEA352B03143E188838ABE5840F690CB0388 09DD74F927A1CEA352B03143E188838ABE5840F690CB0388
677FA624A3775FD7CBC4E8409EC9816BE32FA474733B0F98 677FA624A3775FD7CBC4E8409EC9816BE32FA474733B0F98
C27FBAEDBBC9963B9CB5ECC03C3E35B3AFC0B7B35B495DEA C27FBAEDBBC9963B9CB5ECC03C3E35B3AFC0B7B35B495DEA
C0997122EA867F07B8D5EB', C0997122EA867F07B8D5EB',
{ {
/ A CBOR-encoded byte-string-wrapped EAT claims-set. It / / A CBOR-encoded byte-string-wrapped EAT claims-set. /
/ contains claims suitable for a TEE. / / It contains claims for a simple TEE attestation. /
"TEE" : h'a40a48948f8860d13a463e190106f519010702 "TEE" : h'a40a5048df7b172d70b5a18935d0460a73dd7119
190111818218795858a60064336132340c0101 0106f51901070219011081821901025858a60064
6b41636d6520544545204f530d65332e312e34 336132340c01016b41636d6520544545204f530d
0282a2181f6b41636d6520544545204f531821 65332e312e340282a2181f6b41636d6520544545
01a2181f6b41636d6520544545204f53182102 204f53182101a2181f6b41636d6520544545204f
06a111a118186e61636d655f7465655f332e65 5318210206a111a118186e61636d655f7465655f
7865' 332e657865'
} }
]) ])
/ This example contains a submodule that is a detached digest, / / This example contains a submodule that is a detached digest, /
/ which is the hash of a Claims-Set conveyed outside this / / which is the hash of a Claims-Set conveyed outside this /
/ token. Additionally, there is an example of a token from an / / token. It is also an example of a token from an attestation /
/ attestation HW block. / / hardware block. /
{ {
/ eat_nonce / 10: h'3515744961254b41a6cf9c02', / eat_nonce / 10: h'3515744961254b41a6cf9c02',
/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea', / ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',
/ oemid / 258: 64242, / Private Enterprise Number / / oemid / 258: 64242, / Private Enterprise Number /
/ oemboot / 262: true, / oemboot / 262: true,
/ dbgstat / 263: 3, / disabled-permanently / / dbgstat / 263: 3, / disabled-permanently /
/ hwversion / 260: [ "3.1", 1 ], / multipartnumeric / / hwversion / 260: [ "3.1", 1 ], / multipartnumeric /
/ submods/ 266: { / submods/ 266: {
"TEE": [ / detached digest submod / "TEE": [ / detached digest submod /
-16, / SHA-256 / -16, / SHA-256 /
h'e5cf95fd24fab7144674 h'ab86f765643aabfd09c8
2dd58d43dae178e55fe2 4eebe150b7f61bc24804
b94291a9291082ffc263 cee75e90c5f99cb850fe
5a0b' 808f'
] ]
} }
} }
A.2.3. JSON-Encoded Detached EAT Bundle A.2.3. JSON-Encoded Detached EAT Bundle
In this bundle, there are two detached Claims-Sets: "Audio Subsystem" In this bundle, there are two detached Claims-Sets: "Audio Subsystem"
and "Graphics Subsystem". The JWT at the start of the bundle has and "Graphics Subsystem". The JWT at the start of the bundle has
detached signature submodules with hashes that cover these two detached signature submodules with hashes that cover these two
Claims-Sets. The JWT itself is protected using the Hashed Message Claims-Sets. The JWT itself is protected using the Hashed Message
Authentication Code (HMAC) with a key of "xxxxxx". Authentication Code (HMAC) with a key of "xxxxxx".
The lines in this example are wrapped per [RFC8792]. The lines in this example are wrapped per [RFC8792].
=============== NOTE: '\' line wrapping per RFC 8792 ================
[ [
[ [
"JWT", "JWT",
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlYXRfbm9uY2UiOiJ5dT\ "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlYXRfbm9uY2UiOiJ5dT\
c2Tk44SXVWNmUiLCJzdWJtb2RzIjp7IkF1ZGlvIFN1YnN5c3RlbSI6WyJESUdFU1QiLF\ c2Tk44SXVWNmUiLCJzdWJtb2RzIjp7IkF1ZGlvIFN1YnN5c3RlbSI6WyJESUdFU1QiLF\
siU0hBLTI1NiIsIkZSRW4yVlR3aTk5cWNNRVFzYmxtTVFnM2I1b2ZYUG5OM1BJYW5CME\ siU0hBLTI1NiIsIkZSRW4yVlR3aTk5cWNNRVFzYmxtTVFnM2I1b2ZYUG5OM1BJYW5CME\
5RT3MiXV0sIkdyYXBoaWNzIFN1YnN5c3RlbSI6WyJESUdFU1QiLFsiU0hBLTI1NiIsIk\ 5RT3MiXV0sIkdyYXBoaWNzIFN1YnN5c3RlbSI6WyJESUdFU1QiLFsiU0hBLTI1NiIsIk\
52M3NqUVU3Q1Z0RFRka0RTUlhWcFZDNUNMVFBCWmVQWWhTLUhoVlZWMXMiXV19fQ.FYs\ 52M3NqUVU3Q1Z0RFRka0RTUlhWcFZDNUNMVFBCWmVQWWhTLUhoVlZWMXMiXV19fQ.FYs\
7R-TKhgAk85NyCOPQlbtGGjFM_3chnhBEOuM6qCo" 7R-TKhgAk85NyCOPQlbtGGjFM_3chnhBEOuM6qCo"
], ],
skipping to change at line 3955 skipping to change at line 3962
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 4024 skipping to change at line 4032
DevID certificate. These EAT claims can represent all the same DevID certificate. These EAT claims can represent all the same
fields and values that can be put in a DevID certificate subject. fields and values that can be put in a DevID certificate subject.
EAT explicitly and carefully defines a variety of useful claims. EAT explicitly and carefully defines a variety of useful claims.
EAT secures the conveyance of these claims by having them signed on EAT secures the conveyance of these claims by having them signed on
the device by the attestation key when the EAT is generated. EAT the device by the attestation key when the EAT is generated. EAT
also signs the nonce that gives freshness at this time. Since these also signs the nonce that gives freshness at this time. Since these
claims are signed for every EAT generated, they can include things claims are signed for every EAT generated, they can include things
that vary over time such as GPS location. that vary over time such as GPS location.
DevID secures the device identity fields when they are signed by the DevID secures the device identity fields by embedding them in a
manufacturer of the device into a certificate. That certificate is certificate and signing it. The certificate is created once during
created once during the manufacturing of the device and never manufacturing and remains unchanged.
changes, so the fields cannot change.
So in one case, the signing of the identity happens on the device, So in one case, the signing of the identity happens on the device,
and in the other case, it happens in a manufacturing facility. and in the other case, it happens in a manufacturing facility.
However, in both cases, the signing of the nonce that proves the However, in both cases, the signing of the nonce that proves the
binding to the actual device happens on the device. binding to the actual device happens on the device.
While EAT does not specify how the signing keys, signature process, While EAT does not specify how the signing keys, signature process,
and storage of the identity values should be secured against attack, and storage of the identity values should be secured against attack,
an EAT implementation may have equal defenses against attack. One an EAT implementation may have equal defenses against attack. One
reason EAT uses CBOR is because it is simple enough that a basic EAT reason EAT uses CBOR is because it is simple enough that a basic EAT
skipping to change at line 4072 skipping to change at line 4079
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 4124 skipping to change at line 4129
exp-claim-label = JC<"exp", 4> exp-claim-label = JC<"exp", 4>
nbf-claim-label = JC<"nbf", 5> nbf-claim-label = JC<"nbf", 5>
iat-claim-label = JC<"iat", 6> iat-claim-label = JC<"iat", 6>
cti-claim-label = CBOR-ONLY<7> ; jti in JWT: different name and text cti-claim-label = CBOR-ONLY<7> ; jti in JWT: different name and text
JSON-ONLY<J> = J .feature "json" JSON-ONLY<J> = J .feature "json"
CBOR-ONLY<C> = C .feature "cbor" CBOR-ONLY<C> = C .feature "cbor"
JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C> JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C>
; Same as JC<> but with unwound generic nesting as it seems to cause
; problems. Perhaps this is the nesting problem described in RFC
; 8610.
JC-NEST-SAFE<J,C> = J .feature "json" / C .feature "cbor"
; A JWT message is either a JSON Web Signature (JWS) or a JSON Web ; A JWT message is either a JSON Web Signature (JWS) or a JSON Web
; Encryption (JWE) in compact serialization form with the payload ; Encryption (JWE) in compact serialization form with the payload
; as a Claims-Set. Compact serialization is the protected headers, ; as a Claims-Set. Compact serialization is the protected headers,
; payload, and signature that are each b64url-encoded and separated ; payload, and signature that are each b64url-encoded and separated
; by a ".". This CDDL simply matches the top-level syntax of a JWS ; by a ".". This CDDL simply matches the top-level syntax of a JWS
; or JWE as it is not possible to do more in CDDL. ; or JWE as it is not possible to do more in CDDL.
JWT-Message = JWT-Message =
text .regexp "[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+" text .regexp "[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+"
; 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)
; An untagged CWT may be a COSE tag or not. ; An untagged CWT may be a COSE tag or not.
CWT-Untagged-Message = COSE_Messages CWT-Untagged-Message = COSE_Messages
Appendix E. New Claim Design Considerations Appendix E. New Claim Design Considerations
The following are design considerations that may be helpful to take The following are design considerations that may be helpful to take
into account when creating new EAT claims. This is the product of into account when creating new EAT claims. This is the product of
discussion in the RAT Working Group. discussion in the RATS Working Group.
EAT reuses the CWT and JWT claims registries. There is no registry EAT reuses the CWT and JWT claims registries. There is no registry
exclusively for EAT claims. This is not an update to the expert exclusively for EAT claims. This is not an update to the expert
review criteria for the JWT and CWT claims registries as that would review criteria for the JWT and CWT claims registries as that would
be an overreach for this document. be an overreach for this document.
E.1. Interoperability and Relying Party Orientation E.1. Interoperability and Relying Party Orientation
It is a broad goal that EATs can be processed by relying parties in a It is a broad goal that EATs can be processed by relying parties in a
general way regardless of the type, manufacturer, or technology of general way regardless of the type, manufacturer, or technology of
skipping to change at line 4208 skipping to change at line 4208
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
skipping to change at line 4377 skipping to change at line 4377
Paul Crowley Paul Crowley
Authors' Addresses Authors' Addresses
Laurence Lundblade Laurence Lundblade
Security Theory LLC Security Theory LLC
Email: lgl@securitytheory.com Email: lgl@securitytheory.com
Giridhar Mandyam Giridhar Mandyam
Mediatek USA
Email: giridhar.mandyam@gmail.com Email: giridhar.mandyam@gmail.com
Jeremy O'Donoghue Jeremy O'Donoghue
Qualcomm Technologies Inc. Qualcomm Technologies Inc.
279 Farnborough Road 279 Farnborough Road
Farnborough Farnborough
GU14 7LS GU14 7LS
United Kingdom United Kingdom
Phone: +44 1252 363189 Phone: +44 1252 363189
Email: jodonogh@qti.qualcomm.com Email: jodonogh@qti.qualcomm.com
 End of changes. 120 change blocks. 
293 lines changed or deleted 292 lines changed or added

This html diff was produced by rfcdiff 1.48.