Network Working Group S. Frost
Internet-Draft Arm Limited
Intended status: Informational T. Fossati
Expires: 11 March 2027 Linaro
G. Mandyam
Advanced Micro Devices Inc
7 September 2026
Arm's Confidential Compute Architecture Reference Attestation Token
draft-ffm-rats-cca-token-04
Abstract
The Arm Confidential Compute Architecture (CCA) is series of hardware
and software innovations that enhance Arm’s support for Confidential
Computing for large, compute-intensive workloads. Devices that
implement CCA can produce attestation tokens as described in this
memo, which are the basis for trustworthiness assessment of the
Confidential Compute environment. This document specifies the CCA
attestation token structure and semantics.
The CCA attestation token is a profile of the Entity Attestation
Token (EAT). This specification describes what claims are used in an
attestation token generated by CCA compliant systems, how these
claims get serialized to the wire, and how they are cryptographically
protected.
This informational document is published as an independent submission
to improve interoperability with Arm's architecture. It is not a
standard nor a product of the IETF.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction
2. Conventions and Definitions
3. CCA Attester Model
3.1. Direct
3.2. Delegated
3.3. Boot Phase
3.4. Run-time Phase
4. CCA Claims
4.1. CCA Attestation Token top level wrapper
4.2. CCA Platform token Claims
4.3. Caller Claims
4.3.1. CCA Platform Workload Binding
4.3.2. CCA Platform Challenge
4.3.3. Platform to Realm Binding compatibility
4.4. Target Identification Claims
4.4.1. CCA Platform Instance ID
4.4.2. CCA Platform Implementation ID
4.5. Target State Claims
4.5.1. CCA Platform Profile Definition
4.5.2. Security Lifecycle
4.5.3. Platform Config
4.5.4. Platform Manufacturing Config
4.6. Software Inventory Claims
4.6.1. Software Components
4.6.2. CCA Platform Hash Algorithm ID
4.6.3. CCA Platform Client ID
4.6.4. CCA Platform Manufacturing Config
4.6.5. CCA Platform Extension
4.6.6. CCA Platform Peer Signers
4.6.7. CCA Platform Discrete TPM Binding Data
4.6.8. CCA Platform TBB ROTPK
4.7. Verification Claims
4.7.1. Verification Service Indicator
4.8. CCA Realm state token Claims
4.8.1. CCA Realm Challenge
4.8.2. Realm Profile Definition
4.8.3. Realm Personalisation Value
4.8.4. Realm Initial Measurement
4.8.5. Realm Extensible Measurements
4.8.6. Realm Hash Algorithm Measurements
4.8.7. Realm Public Key
4.8.8. Realm Public Key Hash Algorithm ID
4.8.9. Realm MEC Policy
4.8.10. Realm LFA Policy
4.8.11. Realm Instance ID
4.8.12. Realm Devices Token Hash
4.9. Device Token
4.9.1. Selectively Assigned Devices Token
4.9.2. Comprehensive Trust Devices Token
4.10. Token Binding
4.11. Reference Profile
4.11.1. Token Encoding and Signing
4.11.2. Freshness Model
4.11.3. Synopsis
5. Collated CDDL
6. Signing key implementation alternatives
7. CCA Attestation Token Verification
7.1. Live Firmware Activation (LFA)
7.2. AR4SI Trustworthiness Claims Mappings
7.3. Endorsements, Reference Values and Verification Key
Material
8. Implementation Status
9. Security and Privacy Considerations
10. IANA Considerations
10.1. CBOR Web Token Claims Registration
10.1.1. Arm CCA Attestation CMW
10.1.2. Security Lifecycle Claim
10.1.3. Implementation ID Claim
10.1.4. Software Components Claim
10.1.5. Verification Service Indicator Claim
10.1.6. Platform Config Claim
10.1.7. Platform Hash Algorithm ID Claim
10.1.8. Platform Manufacturing Config
10.1.9. Platform Extension
10.1.10. Platform TBB RoTPK
10.1.11. Platform Peer Signers
10.1.12. Platform Device TPM Binding Data
10.1.13. Platform Workload Binding
10.1.14. CCA Token Platform Token Label
10.1.15. Realm Personalization Value Claim
10.1.16. Realm Hash Algorithm ID Claim
10.1.17. Realm Public Key Claim
10.1.18. Realm Initial Measurement Claim
10.1.19. Realm Extensible Measurements Claim
10.1.20. Realm Public Key Hash Algorithm ID Claim
10.1.21. Realm MEC Policy
10.1.22. Realm LFA Policy
10.1.23. Realm Devices Token Hash
10.1.24. CCA Token Delegated Realm Token Label
10.2. Media Types
10.3. CoAP Content-Formats Registration
10.3.1. Registry Contents
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Examples
A.1. Delegated Mode
A.1.1. Platform Claims Set
A.1.2. Realm Claims Set
A.1.3. Platform Attestation Key
A.1.4. Realm Attestation Key
A.1.5. Signed and Bound Assembly
A.2. Direct Mode
Acknowledgments
Contributors
Authors' Addresses
1. Introduction
The Arm Confidential Compute Architecture (CCA) [CCA-ARCH] is a set
of hardware [RME] and firmware [RMM] specifications, backed by a
reference implementation [TF-RMM] .
CCA provides confidential compute environments, called Realms, that
can be dynamically allocated by the Normal world host. The initial
state of a Realm, and of the platform on which it executes, can be
attested. Attestation allows the Realm owner to establish trust in
the Realm, before provisioning any secrets to it. The Realm does not
have to inherit the trust from the Non-secure hypervisor which
controls it.
As outlined in the RATS Architecture [RFC9334], an Attester produces
a signed collection of Claims that constitutes Evidence about its
target environment. This document focuses on the output provided by
requests from the Realm to the Realm Management Monitor (RMM)
management component for an attestation token that covers the state
of that Realm and the CCA Platform. This output corresponds to
Evidence in [RFC9334] and, as a design decision, the CCA attestation
token is a profile of the Entity Attestation Token (EAT) [EAT]. Note
that there are other profiles of EAT available, such as
[I-D.kdyxy-rats-tdx-eat-profile] and [I-D.mandyam-rats-qwestoken],
for use with different use cases and by different attestation
technologies.
Since the CCA tokens are consumed by services outside the device,
there is an actual need to ensure interoperability. Interoperability
needs are addressed here by describing the exact syntax and semantics
of the attestation claims, and defining the way these claims are
encoded and cryptographically protected.
Further details on concepts expressed below can be found in the Realm
Management Monitor specification 2.0 [RMM].
As mentioned in the abstract, this memo documents a vendor extension
to the RATS architecture, and is not a standard.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The terms Attester, Relying Party, Verifier, Attestation Result,
Target Environment, Attesting Environment and Evidence are defined in
[RFC9334]. We use the term "receiver" to refer to Relying Parties
and Verifiers.
We use the terms Evidence, "CCA attestation token", and "CCA token"
interchangeably. The terms "sender" and Attester are used
interchangeably. Likewise, we use the terms Verifier and
"verification service" interchangeably.
RoT:
Root of Trust, the minimal set of software, hardware and data that
has to be implicitly trusted in the platform - there is no
software or hardware at a deeper level that can verify that the
Root of Trust is authentic and unmodified. An example of a RoT
suitable for CCA would be an isolated Trusted subsystem
responsible for initial measurements, lifecycle state management,
identity and attestation services. The services that the RoT
provides for securitization of the CCA environment are described
as Hardware-Enforced Security (HES) - see Section B4.1.5 of
[RME-SYSARCH].
Realm-World:
Realm World, provides a security state and physical address range
that provides an execution environment for VMs that is isolated
from the Normal and Secure worlds. The controlling firmware
running in the Realm world can access memory in the Normal world
to allow shared buffers. (This is similar to Trusted Execution
Environment (TEE), "secure world", or "secure enclave".)
Realm:
the Realm execution environment, is an Arm CCA environment that
can be dynamically allocated by the Normal world Host.
NW-Host:
Normal world host, refers to the security domain outside of the
restricted Root, Secure and Realm worlds. This typically contains
the host hypervisor and supervisory services. The NW-Host can
allocate and manage resource allocation and can manage the
scheduling for other worlds.
In this document, the structure of data is specified in Concise Data
Definition Language (CDDL) [RFC8610].
3. CCA Attester Model
There are two kinds of CCA Attester: direct and delegated. Their
architectural arrangements are described in Section 3.1 and
Section 3.2, respectively.
Both arrangements implement a "layered attester" (Section 3.2 of
[RFC9334]) with exactly two layers: platform and realm.
The Realm Management Monitor (RMM) is the top layer Attesting
Environment. It attests to the initial memory content of each Realm
that is executed on a CCA platform, any dynamic measurements provided
by Realm guest code and aditional evidence about the state of a
Realm.
The HES (Hardware Enforced Security) is the bottom layer Attesting
Environment, which acts as the CCA platform hardware RoT. It attests
to the executables and configuration contents of the "Monitor
Security Domain", which includes the RMM, as well as the identity,
configuration and state of the CCA platform. This produces a set of
claims forming the CCA Platform evidence.
The following architecture applies to both following attester models.
.----------.
| |
| Verifier |
| |
'----------'
^
.-----------------------------------. |
| .-------------. | |
| | Target | | |
| | Environment +----. | | Layered
| | | TE | | | Evidence for
| | Realm 1 | +----. | | Platform and
| '-+--+--------' | TE | | | Realm
| | | Realm 2 | | | |
| | '-+--+--------' | | |
| | | | ... | | |
| | | '-+-----------' | |
| | | | Collect Claims | |
| .----| ---|----|----------------. | |
| | v v v Target | | |
| | .-----------. Environment | | |
| | | Realm | | | |
| | | Management +-------------------'
| | | Monitor | .----------. | |
| | | (RMM) | | BLs | | |
| | | | '----------' | |
| | | | | |
| | | Attesting | .----------. | |
| | | Environment | | CFGs | | |
| | '-----------' '----------' | |
| | ^ Platform | |
| '----|--------------+-----------' |
| | Evidence | Collect |
| | for | Claims |
| | Platform v |
| .---+----------------------. |
| | Hardware | |
| | Enforced | |
| | Security Attesting | |
| | (HES) Environment | |
| '--------------------------' |
'-----------------------------------'
Figure 1: CCA Attester
3.1. Direct
The structure of the CCA direct Attester is illustrated in TODO-fig-
cca-direct-attester.
In the direct model, the RMM creates a set of claims that represent
the state of a Realm. This set of claims is hashed and that hash is
passed to the HES when requesting the CCA Platform evidence. This
hash is included in a claim within the CCA Platform evidence. The
platform evidence is signed using the CCA Platform Attestation Key
(CPAK).
The CCA Evidence produced with the direct model comprises a signed
EAT for the platform token and an unsigned EAT for the realm token,
wrapped in a CMW [CMW] collection. The intra-collection binding is
detailed in Section 4.10.
change addresses: Issue #16 (https://github.com/SimonFrost-Arm/draft-
ffm-rats-cca-token/issues/16)
3.2. Delegated
The structure of the CCA delegated Attester is illustrated in
Figure 1.
In the delegated model, the RMM uses its own private key called RAK
(Realm Attestation Key) to sign the claims regarding the requesting
Realm.
The RAK keypair is derived within the HES. The RAK is transferred
over a trusted channel to the RMM. The platform evidence include a
claim containg a hash of the RAK public key. The platform evidence
is signed using the CCA Platform Attestation Key (CPAK).
The CCA Evidence produced in delegated mode comprises two separately
signed EATs, one for the platform, another for the realm, wrapped in
a CMW [CMW] collection. The intra-collection binding is detailed in
Section 4.10.
TODO: Device Token
3.3. Boot Phase
The HES Attesting Environment is responsible for collecting the
information to be represented in CCA platform claims and to assemble
them into Evidence.
The Main Bootloader, executing at boot-time, measures the trusted
computing base (TCB) of the Realm World - i.e., loaded firmware
components and the associated configuration payloads - and sends them
to the HES RoT to be stored isolated. See Figure 2.
i-th Target Main Boot HES
Environment Loader RoT
| | |
.--------|-------------|-------------|----.
| loop i | | | |
| | measure | | |
| |o------------+ | |
| | | write | |
| | | measurement | |
| | +------------>| |
'--------|-------------|-------------|----'
| | |
Figure 2: CCA Attester Boot Phase
3.4. Run-time Phase
The Realm Management Monitor (RMM), executing at run-time, maintains
measurements for the state of a Realm. It can respond to requests
issued from a Realm for an attestation token relevant for that Realm
by obtaining a CCA Platform attestation token from the HES RoT and
combining that with an attestation token containing Evidence
reflecting Realm state.
The HES RoT, executing at run-time, maintains measurements for the
state of the CCA platform TCB, including the lifecycle state of the
CCA platform. It can answer requests coming from the RMM to collect
and format claims corresponding to that state and use a CCA Platform
Attestation Key (CPAK) to sign them (see Figure 3). How the CPAK is
derived is implementation-specific.
HES Realm
RoT Manager Verifier
| | |
| | |
Platform | | |
Boot | | |
State | Req. Platform | |
| | Token (#RAK) | |
| |<--------------+ |
v | | |
Platform | | |
Token | | |
| | |
sign .---+ | |
w/ | | | |
CPAK '-->| Plat Token | |
+-------------->| |
| | |
| Realm | |
| State | |
| | | |
| | | |
| v | |
| Realm | |
| Token | |
| | |
| sign .---+ |
| w/ | | |
| RAK '-->| |
| | |
| | |
| | CCA Token |
| +---------->|
| | |
Figure 3: CCA Attester Run-time Phase
A reference implementation of the CCA Attester is provided by
[TF-RMM].
4. CCA Claims
This section describes the claims to be used in a CCA reference
attestation token.
There are two logical sections within the CCA attestation token,
relating to the two Target Environment elements:
* The CCA Platform token
* The Realm state token
The two sections use inter-related claims to bind together into a
single logical unit. See Section 9 for more details.
The above tokens are presented to the requester within a top level
Conceptual Message Wrapper (CMW) collection [CMW].
This profile conforms to the claims in the Beta3 release of the 2.0
version of the Realm Management Monitor specification [RMM].
The CDDL within this draft conforms to the claim set at the latest
profile version. See compatibility statements within the description
of each claim to determine status in earlier profile versions.
This profile does not include any coverage for CCA Platform or Realm
claims prior to the Alpha 14 release of the 1.1 version of the Realm
Management Monitor specification [RMM].
CDDL [RFC8610] along with text descriptions is used to define each
claim independent of encoding. The following CDDL type(s) are reused
by different claims:
arm-platform-hash-type = bytes .size 32 /
bytes .size 48 /
bytes .size 64
4.1. CCA Attestation Token top level wrapper
The above tokens are presented to the requester within a top level
CMW collection [CMW]. The collection map has two core entries, one
for a bstr encoding of the CCA Platform token and the other for a
bstr encoding of the Realm state token. The type of the CMW entry
will vary for the Realm state token depending on whether the
delegated or direct attestation model is used by an implementation.
Depending upon the features within a CCA implementation there may be
additional entries within the CMW. These can include:
* A Firmware Activity List (FAL), used to support verification of
the effect of Live Firmware Activation on the CCA Platform
Section 7.1.
* Device Token - where a Realm has device(s) selectively assigned,
the Device Token provides binding hashes to the device evidence
Section 4.9.
* Selective Device Token - contains evidence obtained from
selectively assigned devices Section 4.9.1.
* Comprehensive Device Token - contains evidence obtained from
comprehensively trusted devices Section 4.9.2.
* Certificate Chain information optionally included to support an
inline leaf endorsement certificate Section 6.
; CMW (draft-ietf-rats-msg-wrap) Collection
cca-token = #6.907(cca-token-cmw)
; CoAP Content-Format for "application/eat+cwt"
eat-cwt-coap-cf = 263
cca-token-cmw = {
0xACCA => [
eat-cwt-coap-cf
bytes .cbor COSE_Sign1<arm-platform-claims>
]
0xACD1 => [
eat-cwt-coap-cf
bytes .cbor COSE_Sign1<cca-realm-claims>
]
}
4.2. CCA Platform token Claims
4.3. Caller Claims
4.3.1. CCA Platform Workload Binding
The Workload Binding claim provides the basis for a cryptographic
binding to be established between the CCA Platform and CCA Realm
attestation tokens.
The value of the workload binding claim varies by the implemented
attestation model. See Section 4.3.3 for further details.
The length of the value of the claim MUST be either 32, 48, or 64
bytes.
This claim MUST be present in a CCA Platform attestation token.
Compatibility: this claim will be present where profile values are at
or newer than "tag:arm.com,2026:cca_platform#2.0.0".
arm-platform-workload-binding-label = 2408
arm-platform-workload-binding = (
arm-platform-workload-binding-label => arm-platform-hash-type
)
4.3.2. CCA Platform Challenge
If an implementation uses a different attestation model to the
default delegated model, a CCA platform challenge claim can be
present in the platform attestation token. This claim is used to
carry a challenge provided by the relying party to demonstrate
freshness of the generated token.
This claim is OPTIONAL in a CCA Platform attestation token.
See Section 4.3.3 for further details on when the claim may be
present.
The [EAT] eat_nonce (claim key 10) is used. Since the EAT nonce
claim offers flexiblity for different attestation technologies, this
specifications applies the following constraints to the nonce-type:
* The length MUST be either 32, 48, or 64 bytes.
* Only a single nonce value is conveyed. The array notation MUST
NOT be used for encoding the nonce value.
arm-platform-challenge-label = 10
arm-platform-challenge = (
arm-platform-challenge-label => arm-platform-hash-type
)
4.3.3. Platform to Realm Binding compatibility
All versions of the CCA profile have had a mechanism to hold a
binding between the CCA Platform and CCA Realm attestation tokens.
The claims used vary by profile version and attestation model
implemented as outlined below.
4.3.3.1. Profile tag:arm.com,2024:cca_platform#1.1.0
* Attestation Model: Delegated
* Binding Claim: eat_nonce
* Claim Value: H(RAK public)
4.3.3.2. Profile tag:arm.com,2024:cca_platform#2.0.0
* Attestation Model: Delegated
* Binding Claim: eat_nonce
* Claim Value: H(RAK public)
4.3.3.3. Profile tag:arm.com,2024:cca_platform#2.0.0;direct
* Attestation Model: Direct
* Binding Claim: eat_nonce
* Claim Value: H(realm claims)
4.3.3.4. Profile tag:arm.com,2026:cca_platform#2.0.0
* Attestation Model: Delegated
* Binding Claim: eat_nonce
* Claim Value: H(RAK public)
* Equivalent profile value:
tag:arm.com,2026:cca_platform#2.0.0;delegated
4.3.3.5. Profile tag:arm.com,2026:cca_platform#2.0.0;direct
* Attestation Model: Direct
* Binding Claim: eat_nonce
* Claim Value: H(realm claims)
4.3.3.6. Profile tag:arm.com,2026:cca_platform#2.0.0;HESRAK
* Attestation Model: Delegated attestation, with the RAK kept within
the HES
* Binding Claim: eat_nonce
* Claim Value: H(RAK public)
* Note: for this attestation model, the PAT also contains an
eat_nonce claim with the value equal to the CCA Realm challenge
claim.
4.3.3.7. Profile tag:arm.com,2026:cca_platform#2.1.0
* Attestation Model: Delegated
* Binding Claim: eat_nonce
* Claim Value: H(RAK public)
* Equivalent profile value:
tag:arm.com,2026:cca_platform#2.1.0;delegated
4.3.3.8. Profile tag:arm.com,2026:cca_platform#2.1.0;direct
* Attestation Model: Direct
* Binding Claim: eat_nonce
* Claim Value: H(realm claims)
4.3.3.9. Profile tag:arm.com,2026:cca_platform#2.0.0;HESRAK
* Attestation Model: Delegated attestation, with the RAK kept within
the HES
* Binding Claim: eat_nonce
* Claim Value: H(RAK public)
* Note: for this attestation model, the PAT also contains an
eat_nonce claim with the value equal to the CCA Realm challenge
claim.
4.3.3.10. Binding claim Notes
For the delegated attestation models, RAK public is a COSE_Key
structure. The hash algorithm used to generate H(RAK public) is that
detailed in cca-realm-public-key-hash-algo-id.
For the direct attestation model, the Realm Claims are an Untagged
Claims set as defined in https://datatracker.ietf.org/doc/draft-ietf-
rats-uccs/. The hash algorithm used to generate H(realm claims) is
that detailed in cca-realm-hash-algo-id.
The CCA platform challenge claim MUST NOT be present when the CCA
platform profile claim has any of the following values:
* tag:arm.com,2026:cca_platform#2.0.0
* tag:arm.com,2026:cca_platform#2.0.0;delegated
* tag:arm.com,2026:cca_platform#2.0.0;direct
* tag:arm.com,2026:cca_platform#2.1.0
* tag:arm.com,2026:cca_platform#2.1.0;delegated
* tag:arm.com,2026:cca_platform#2.1.0;direct
4.4. Target Identification Claims
4.4.1. CCA Platform Instance ID
The Instance ID claim is a unique identifier of this Platform
instance. It can be used by a verifier to help locate an endorsement
for the Attestation Key (PAK).
The EAT ueid (claim key 256) of type RAND is used. The following
constraints apply to the ueid-type:
* The length MUST be 33 bytes.
* The first byte MUST be 0x01 (RAND) followed by the 32-byte unique
identifier.
eat-ueid-rand-type = bytes .join eat-ueid-rand-fmt
eat-ueid-rand-fmt = [
; the type byte is 0x01
ueid-rand-typ
bytes .size 32
]
ueid-rand-typ = h'01'
This claim MUST be present in a CCA Platform attestation token.
Compatibility: this claim will be present for all values of CCA
Platform Profile.
arm-platform-instance-id-label = 256 ; EAT ueid
arm-platform-instance-id-type = eat-ueid-rand-type
arm-platform-instance-id = (
arm-platform-instance-id-label => arm-platform-instance-id-type
)
4.4.2. CCA Platform Implementation ID
The Implementation ID claim uniquely identifies the implementation of
the CCA Platform. The value of the CCA platform Implementation ID
claim can be used by a verification service to locate the details of
the CCA platform implementation from an endorser or manufacturer.
Such details are used by a verification service to determine the
security properties or certification status of the CCA Platform
implementation.
The value and format of the ID is decided by the manufacturer or a
particular certification scheme. For example, the ID could take the
form of a product serial number, database ID, or other appropriate
identifier.
This claim MUST be present in a CCA Platform attestation token.
Compatibility: this claim will be present for all values of CCA
Platform Profile.
Note that this identifies the CCA Platform implementation, not a
particular instance. To uniquely identify an instance, see the
Instance ID claim Section 4.4.1.
arm-platform-implementation-id-label = 2396 ; PSA implementation ID
arm-platform-implementation-id-type = bytes .size 32
arm-platform-implementation-id = (
arm-platform-implementation-id-label =>
arm-platform-implementation-id-type
)
4.5. Target State Claims
4.5.1. CCA Platform Profile Definition
The CCA platform profile claim identifies the EAT profile to which
the CCA platform token conforms. This allows a receiver to assign
the intended semantics to the rest of the claims found in the token.
The EAT eat_profile (claim key 265) is used.
The format of the CCA platform profile claim is defined as a text
string of value "tag:arm.com,2024:cca_platform#2.0.0".
This claim MUST be present in a CCA Platform attestation token.
Compatibility: this claim will be present for all values of CCA
Platform Profile.
arm-platform-profile-label = 265 ; EAT profile
arm-platform-profile-type = "tag:arm.com,2026:cca_platform#2.0.0" /
"tag:arm.com,2026:cca_platform#2.0.0;delegated" /
"tag:arm.com,2026:cca_platform#2.0.0;HESRAK" /
"tag:arm.com,2026:cca_platform#2.0.0;direct" /
"tag:arm.com,2026:cca_platform#2.1.0" /
"tag:arm.com,2026:cca_platform#2.1.0;delegated" /
"tag:arm.com,2026:cca_platform#2.1.0;HESRAK" /
"tag:arm.com,2026:cca_platform#2.1.0;direct"
arm-platform-profile = (
arm-platform-profile-label => arm-platform-profile-type
)
4.5.2. Security Lifecycle
The Security Lifecycle claim represents the current lifecycle state
of the CCA Platform.
The state is represented by an integer that is divided as follows:
* major[15:8] - CCA Platform security lifecycle state, and
* minor[7:0] - IMPLEMENTATION DEFINED state.
The CCA Platform lifecycle states are illustrated in Figure 4. A non
debugged CCA platform will be in arm-platform-lifecycle-secured
state. Realm Management Security Domain debug is always recoverable,
and would therefore be represented by arm-platform-lifecycle-non-
platform-rot-debug state. Root world debug is recoverable on a HES
system and would be represented by arm-platform-lifecycle-
recoverable-platform-rot state. On a non-HES system Root world debug
is usually non-recoverable, and would be represented by arm-platform-
lifecycle-lifecycle-decommissioned state
This claim MUST be present in a CCA Platform attestation token.
Compatibility: this claim will be present for all values of CCA
Platform Profile.
.--------------------------.
| Device Assembly and Test |
'------------+-------------'
| Device
| Lockdown
v
.----------------------------.
| CCA Security Provisioning |
'-----------+----------------'
|
Provisioning | .---------------------.
Lockdown | | |
v v |
.----------------. |Recoverable
.--------------+ Secured +--------. |
| '-+--------------' | |
Non | ^ Recoverable |
Recoverable RM Debug | Root Debug |
Root Debug Enable | | |
| | | | |
| v | v |
| .---------- -+--. .-------+-.
| | Realm Manager | | Root |
| | Debug | | Debug |
| '---------------' '--+------'
| |
| .---------------. |
'----------->+ Terminate +<----------'
'---------------'
|
|
v
.----------------.
| Decommissioned |
'----------------'
Figure 4: CCA Platform Lifecycle States
The CDDL representation is shown below. Table 1 provides the
mappings between Figure 4 and the data model.
arm-platform-lifecycle-label = 2395 ; PSA lifecycle
arm-platform-lifecycle-unknown-type = 0x0000..0x00ff
arm-platform-lifecycle-assembly-and-test-type = 0x1000..0x10ff
arm-platform-lifecycle-platform-rot-provisioning-type = 0x2000..0x20ff
arm-platform-lifecycle-secured-type = 0x3000..0x30ff
arm-platform-lifecycle-non-platform-rot-debug-type = 0x4000..0x40ff
arm-platform-lifecycle-recoverable-platform-rot-debug-type = 0x5000..0x50ff
arm-platform-lifecycle-decommissioned-type = 0x6000..0x60ff
arm-platform-lifecycle-type =
arm-platform-lifecycle-unknown-type /
arm-platform-lifecycle-assembly-and-test-type /
arm-platform-lifecycle-platform-rot-provisioning-type /
arm-platform-lifecycle-secured-type /
arm-platform-lifecycle-non-platform-rot-debug-type /
arm-platform-lifecycle-recoverable-platform-rot-debug-type /
arm-platform-lifecycle-decommissioned-type
arm-platform-lifecycle = (
arm-platform-lifecycle-label => arm-platform-lifecycle-type
)
arm-platform-lifecycle-unknown-type is not shown in Figure 4; it
represents an invalid state that must not occur in a system.
+=====================================+====================+
| CDDL | Lifecycle States |
+=====================================+====================+
| arm-platform-lifecycle-unknown-type | |
+-------------------------------------+--------------------+
| arm-platform-lifecycle-assembly- | Assembly and Test |
| and-test-type | |
+-------------------------------------+--------------------+
| arm-platform-lifecycle-platform- | CCA Platform |
| rot-provisioning-type | Provisioning |
+-------------------------------------+--------------------+
| arm-platform-lifecycle-secured-type | Secured |
+-------------------------------------+--------------------+
| arm-platform-lifecycle-non- | Non-Recoverable |
| platform-rot-debug-type | CCA Platform Debug |
+-------------------------------------+--------------------+
| arm-platform-lifecycle-recoverable- | Recoverable CCA |
| platform-rot-debug-type | Platform Debug |
+-------------------------------------+--------------------+
| arm-platform-lifecycle- | Decommissioned |
| decommissioned-type | |
+-------------------------------------+--------------------+
Table 1: Lifecycle States Mappings
4.5.3. Platform Config
The CCA platform config claim describes the set of chosen
implementation options of the CCA platform. As an example, these may
include a description of the level of physical memory protection
which is provided.
The CCA platform config byte string contains implementation
information that is provided by the chip vendor and the device
vendor. This is expected to include the following system properties
(see {RME-SYSARCH}} for details):
* Per-PAS encryption (all RME systems will require this property)
* MEC
* MPE Level
- L0 (none)
- L1 (encryption only)
- L2 (encryption and integrity)
- L3 (anti-replay)
* RME-DA support
* RME-CDA support
The layout and encoding of this information is IMPLEMENTATION
DEFINED.
An attestation verifier should use information from the an
attestation profile document applicable to the implementation to
understand the IMPLEMENTATION DEFINED choices made for this field.
Reference values can be accompanied by a bitmask identifying the
relevant portion of the platform config claim.
This claim MUST be present in a CCA Platform attestation token.
Compatibility: this claim will be present for all values of CCA
Platform Profile.
arm-platform-config-label = 2401 ; PSA platform range
; TBD: add to IANA registration
arm-platform-config-type = bytes
arm-platform-config = (
arm-platform-config-label => arm-platform-config-type
)
4.5.4. Platform Manufacturing Config
The CCA platform manufacturing config claim represents a record of
production phases and testing conducted during the manufacturing
process for this instance.
The CCA platform manufacturing config claim is OPTIONAL in a CCA
platform token
Compatibility: this claim can be present for all values of CCA
Platform Profile.
arm-platform-manufacturing-config-label = 2403
arm-platform-manufacturing-config-type = bytes
arm-platform-manufacturing-config = (
arm-platform-manufacturing-config-label =>
arm-platform-manufacturing-config-type
)
4.6. Software Inventory Claims
4.6.1. Software Components
The Software Components claim is a list of software components which
can affect the behavior of the CCA platform.
This claim MUST be present in a CCA Platform attestation token.
Compatibility: this claim will be present for all values of CCA
Platform Profile.
Each entry in the Software Components list describes one software
component using the attributes described in the following
subsections. Unless explicitly stated, the presence of an attribute
is OPTIONAL.
It is expected that an implementation will describe the expected
software component values within the profile. In some
implementations, a software component may consist of a configuration
data item.
Note that, as described in [RFC9334], a relying party will typically
see the result of the appraisal process from the Verifier in form of
an Attestation Result, rather than the CCA Platform token from the
attesting endpoint. Therefore, a relying party is not expected to
understand the Software Components claim. Instead, it is for the
Verifier to check this claim against the available Reference Values
and provide an answer in form of an "high level" Attestation Result,
which may or may not include the original Software Components claim.
arm-platform-sw-components-label = 2399 ; PSA software components
arm-platform-sw-component = {
? 1 => text, ; component type
2 => arm-platform-hash-type, ; measurement value
? 4 => text, ; version
5 => arm-platform-hash-type, ; signer id
? 6 => text, ; hash algorithm identifier
? 7 => bool, ; live firmware activation supported
? 8 => [ + arm-platform-hash-type ], ; list of countersigner ids
}
arm-platform-sw-components = (
arm-platform-sw-components-label => [ + arm-platform-sw-component ]
)
4.6.1.1. Component Type
The Component Type attribute (key=1) is a short string representing
the role of this software component. This attribute is intended for
use as a hint to help the verifier understand how to evaluate the CCA
platform software component measurement value.
This attribute is optional in a CCA Platform software component.
4.6.1.2. Measurement Value
The Measurement Value attribute (key=2) represents a hash of the
state of the software component in memory at the time it was
initialized. The measurement values are implemented such that the
values can only be extended rather than set. The values are
initialised to 0, so the value reported in attestation will be H(
0 || H(software component)). If the CCA platform supports Live
Firmware Activation then the value reported in attestation may have
been further extended by measurements of updates to the software
component. In this case, the value of the measurement must be
validated by reconstructing the reported value using information from
the Firmware Activity Log
The value MUST be a cryptographic hash of 256 bits or stronger.
This attribute MUST be present in a CCA Platform software component.
The Version attribute (key=4) is the issued software version in the
form of a text string. The meaning of this string is defined by the
software component vendor.
This attribute is optional in a CCA Platform software component.
The Signer ID attribute (key=5) uniquely identifies the signer of the
software component. The identification is typically accomplished by
hashing the signer's public key. The value of this attribute will
correspond to the entry in the original manifest for the component.
This can be used by a Verifier to ensure the components were signed
by an expected trusted source.
This attribute MUST be present in a CCA Platform software component.
4.6.1.5. Measurement Description
The Measurement Description attribute (key=6) contains a string
identifying the hash algorithm used to compute the corresponding
Measurement Value. The string SHOULD be encoded according to "Hash
Name String" in the "Named Information Hash Algorithm Registry"
[IANA.named-information].
4.6.1.6. Live Firmware Activation support
The Live Firmware Activation support attribute (key=7) indicates
whether the component is subject to Live Firmware Activation. If the
attribute is set to false, the component will not be updated before
the next CCA Platform software update.
The Live Firmware Activation support attribute of the CCA Platform
software component is optional.
4.6.1.7. Software Component Countersigner ID List
The Software Component Countersigner ID List (key=8) contains hashes
of public keys which identify signing authorities that provide
additional trustworthiness information for the software component.
These signatures are provided in addition to the primary signature,
which is identified by the CCA platform software component signer ID.
Example use cases for CCA platform software component
countersignatures include:
* An indication of approval for the component, provided by the owner
of the CCA platform
* An indication of approval for the component, provided by a third-
party auditor
The order of multiple entries within the countersigner ID list may
imply a hierarchy. The existence and meaning of any such hierarchy
is IMPLEMENTATION DEFINED.
The Software Component Countersigner ID List attribute is optional in
a CCA Platform software component.
4.6.2. CCA Platform Hash Algorithm ID
The CCA platform hash algorithm ID claim is a text string that
identifies the algorithm used to calculate the extended measurements
in the CCA platform token.
The string SHOULD be encoded according to "Hash Name String" in the
"Named Information Hash Algorithm Registry" [IANA.named-information].
The CCA platform hash algorithm ID claim MUST be present in a CCA
platform token.
Compatibility: this claim will be present for all values of CCA
Platform Profile.
arm-platform-hash-algo-id-label = 2402 ; PSA platform range
; TBD: add to IANA registration
arm-platform-hash-algo-id = (
arm-platform-hash-algo-id-label => text
)
4.6.3. CCA Platform Client ID
The CCA platform client ID claim identifies the security domain from
which the attestation token was requested.
In this profile, the only valid value for the CCA platform client ID
claim is the Realm Management Security Domain (RMSD).
The CCA platform client ID claim MUST be present in a CCA platform
token.
Compatibility: this claim will be present where profile values are at
or newer than "tag:arm.com,2024:cca_platform#2.0.0".
arm-platform-client-id-label = 2394 ; PSA namespace
arm-platform-client-id-rmsd = 1 ; Realm Management Security Domain
arm-platform-client-id-type =
arm-platform-client-id-rmsd
arm-platform-client-id = (
arm-platform-client-id-label => arm-platform-client-id-type
)
4.6.4. CCA Platform Manufacturing Config
The CCA platform manufacturing config claim represents a record of
production phases and testing conducted during the manufacturing
process for this instance.
The values encoding in this claim are implementation defined.
The CCA platform manufacturing config claim is OPTIONAL in a CCA
platform token
Compatibility: this claim can be present for all values of CCA
Platform Profile.
arm-platform-manufacturing-config-label = 2403
arm-platform-manufacturing-config-type = bytes
arm-platform-manufacturing-config = (
arm-platform-manufacturing-config-label =>
arm-platform-manufacturing-config-type
)
4.6.5. CCA Platform Extension
The CCA platform extension claim identifies components which have
been added to the CCA platform at runtime and supplies verification
hashes for evidence obtained from those components.
An example of such a component is a coherent memory (CMEM) device
The CCA platform extension claim is OPTIONAL in a CCA platform token
Compatibility: this claim can be present where profile values are at
or newer than "tag:arm.com,2026:cca_platform#2.1.0".
arm-platform-extension-label = 2404
; protocols that support VCA (Version-Capabilities-Algorithm message concatenation)
$protocols-support-vca /= "spdm-1.2.0"
$protocols-support-vca /= "spdm-1.2.1"
$protocols-support-vca /= "spdm-1.2.2"
$protocols-support-vca /= "spdm-1.2.3"
$protocols-support-vca /= "spdm-1.3.0"
$protocols-support-vca /= "spdm-1.3.1"
$protocols-support-vca /= "spdm-1.3.2"
$protocols-support-vca /= "spdm-1.4.0"
; device types requiring a form of encryption
$type-with-encryption /= "cxl-type-3"
encryption-type = (
host-side-encryption: 0
target-side-encryption: 1
no-encryption: 2
)
arm-platform-extension-device-common = (
? 1 => text, ; hash algorithm identifier
2 => arm-platform-hash-type, ; device measurements exchange digest
3 => arm-platform-hash-type, ; certificate chain digest
4 => bool, ; indicates whether this PDEV uses IDE
)
arm-platform-extension-device = {
arm-platform-extension-device-common
(
( ; ---- VCA digest required ----
5 => $protocols-support-vca, ; protocol, e.g. "spdm-1.2.3"
6 => arm-platform-hash-type, ; SPDM VCA digest
)
// ( ; ---- no VCA needed ----
5 => text ; protocol
)
)
(
(
7 => $type-with-encryption, ; device type, e.g. "cxl-type-3
8 => &encryption-type, ; indicates encryption type
)
// ( ; ---- no encryption type needed ----
7 => text
)
)
}
arm-platform-extension = (
arm-platform-extension-label => [ + arm-platform-extension-device ]
)
4.6.6. CCA Platform Peer Signers
In the event that the CCA platform consists of multiple peer RoTs
which are unable to establish a single attestation signing entity at
boot time, it is necessary for an attestation report produced by one
of those RoTs to identify its peers where execution may be
subsequently scheduled. The CCA platform peer signers claim is used
to provide this information to a verifier.
The CCA platform peer signers claim is OPTIONAL in a CCA platform
token
The data type for this claim is Implementation Defined as different
underlying RoT technologies or provisioning schemes are likely.
Note: this claim is not documented within the Realm Management
Monitor specification [RMM] as it does not apply to the default
implementation.
arm-platform-peer-signers-label = 2406
arm-platform-peer-signers-type = [ + bytes ]
arm-platform-peer-signers = (
arm-platform-peer-signers-label => arm-platform-peer-signers-type
)
4.6.7. CCA Platform Discrete TPM Binding Data
The normal world of a device that supports CCA is outside the TCB of
the confidential computing environment. In some deployments, it is
seen to be desirable to be able to appraise measurements that
indicate the untrusted hypervisor for the device. This is done by
requesting a TPM quote in the normal world and providing it to the
Relying Party together with the CCA Attestation token. The Discrete
TPM Binding Data claim holds data that can be used to prove that the
TPM and the CCA HES belong to the same system.
The CCA platform Discrete TPM Binding Data claim is OPTIONAL in a CCA
platform token
Compatibility: this claim can be present where profile values are at
or newer than "tag:arm.com,2024:cca_platform#2.0.0".
The details of the binding data within this claim are Implementation
Defined, as different underlying TPM binding schemes may be
available.
arm-platform-discrete-tpm-binding-data-label = 2407
arm-platform-discrete-tpm-binding-data-type = bytes
arm-platform-discrete-tpm-binding-data = (
arm-platform-discrete-tpm-binding-data-label => arm-platform-discrete-tpm-binding-data-type
)
4.6.8. CCA Platform TBB ROTPK
Where an implementation of the CCA platform follows the Trusted Board
Boot specification [TBB], the platform will include several
provisioned public key identifiers which are used to establish a
chain of trust. The CCA platform TBB ROTPK claim is used to provide
this information to a verifier.
The CCA platform tbb rotpk claim is OPTIONAL in a CCA platform token
Compatibility: this claim can be present where profile values are at
or newer than "tag:arm.com,2024:cca_platform#2.0.0".
arm-platform-tbb-rotpk-label = 2405
arm-platform-tbb-rotpk-type = [ + arm-platform-tbb-rotpk-item ]
arm-platform-tbb-rotpk-item = {
1 => tstr, ; e.g. "CM" or "DM"
2 => int, ; active ROTPK array
3 => int, ; index in the active array
4 => arm-platform-hash-type ; hash object
}
arm-platform-tbb-rotpk = (
arm-platform-tbb-rotpk-label => arm-platform-tbb-rotpk-type
)
4.7. Verification Claims
The following claims are part of the CCA Platform token (and
therefore still Evidence) but aim to help receivers, including
relying parties, with the processing of the received attestation
Evidence.
4.7.1. Verification Service Indicator
The Verification Service Indicator claim is a hint used by a relying
party to locate a verification service for the token. The value is a
text string that can be used to locate the service (typically, a URI
specifying the address of the verification service API). A Relying
Party may choose to ignore this claim in favor of other information.
Compatibility: this claim will be present for all values of CCA
Platform Profile.
; PSA verification service
arm-platform-verification-service-label = 2400
arm-platform-verification-service-type = text
arm-platform-verification-service = (
arm-platform-verification-service-label =>
arm-platform-verification-service-type
)
It is assumed that the relying party is pre-configured with a list of
trusted verification services and that the contents of this hint can
be used to look up the correct one. Under no circumstances must the
relying party be tricked into contacting an unknown and untrusted
verification service since the returned Attestation Result cannot be
relied on.
Note: This hint requires the relying party to parse the content of
the CCA Platform token. Since the relying party may not be in
possession of a trust anchor to verify the digital signature, it uses
the hint in the same way as it would treat any other information
provided by an external party, which includes attacker-provided data.
The CCA platform verification service indicator claim is OPTIONAL in
a CCA platform token.
4.8. CCA Realm state token Claims
The CCA Realm state token contains claims that represent the Target
Environment that is the Realm that requested the attestation report.
4.8.1. CCA Realm Challenge
The CCA Realm challenge is used to carry a challenge provided by the
Relying Party to demonstrate freshness of the generated token.
The EAT [EAT] nonce (claim key 10) is used. Since the EAT nonce
claim offers flexiblity for different attestation technologies, this
specification applies the following constraints to the nonce-type:
* The length MUST be 64 bytes.
* Only a single nonce value is conveyed. The array notation MUST
NOT be used for encoding the nonce value.
This claim MUST be present in a CCA Realm state attestation token.
Compatibility: this claim will be present for all values of CCA Realm
Profile.
cca-realm-challenge-label = 10
cca-realm-challenge-type = bytes .size 64
cca-realm-challenge = (
cca-realm-challenge-label => cca-realm-challenge-type
)
4.8.2. Realm Profile Definition
The Realm profile claim identifies the EAT profile to which the Realm
token conforms. This allows a receiver to assign the intended
semantics to the rest of the claims found in the token.
The EAT [EAT] eat_profile (claim key 265) is used.
The format of the CCA Realm profile claim is defined as a text string
of value "tag:arm.com,2026:realm#2.0.0".
This claim is OPTIONAL in a CCA Realm attestation token. If the
Realm profile is not included in a CCA Realm token then the profile
value used in the CCA Platform token should refer to a profile that
describes both Platform and Realm claims.
cca-realm-profile-label = 265 ; EAT profile
cca-realm-profile-type = "tag:arm.com,2026:realm#2.0.0"
cca-realm-profile = (
cca-realm-profile-label => cca-realm-profile-type
)
4.8.3. Realm Personalisation Value
The Realm Personalization Value (RPV) claim contains the RPV which
was provided at Realm creation.
This claim MUST be present in a CCA Realm state attestation token.
Compatibility: this claim will be present for all values of CCA Realm
Profile.
cca-realm-personalization-value-label = 44235
cca-realm-personalization-value-type = bytes .size 64
cca-realm-personalization-value = (
cca-realm-personalization-value-label =>
cca-realm-personalization-value-type
)
4.8.4. Realm Initial Measurement
The Realm Initial Measurement claim contains the compound extension
of measurements taken of Realm memory and state before the Realm is
activated.
This claim MUST be present in a CCA Realm state attestation token.
Compatibility: this claim will be present for all values of CCA Realm
Profile.
cca-realm-initial-measurement-label = 44238
cca-realm-initial-measurement = (
cca-realm-initial-measurement-label => cca-realm-measurement-type
)
4.8.5. Realm Extensible Measurements
The Realm Extensible Measurements claim contains measurements
provided by Realm guest software and extended to the set of Realm
Extensible Measurements maintained by the RMM.
This claim MUST be present in a CCA Realm state attestation token.
Compatibility: this claim will be present for all values of CCA Realm
Profile.
cca-realm-extensible-measurements-label = 44239
cca-realm-extensible-measurements = (
cca-realm-extensible-measurements-label =>
[ 4*4 cca-realm-measurement-type ]
)
4.8.6. Realm Hash Algorithm Measurements
The Realm hash algorithm ID claim identifies the algorithm used to
calculate all hash values which are present in the Realm token.
The string value of the claim SHOULD be encoded according to "Hash
Name String" in the "Named Information Hash Algorithm Registry"
[IANA.named-information].
This claim MUST be present in a CCA Realm state attestation token.
Compatibility: this claim will be present for all values of CCA Realm
Profile.
cca-realm-hash-algo-id-label = 44236
cca-realm-hash-algo-id = (
cca-realm-hash-algo-id-label => text
)
4.8.7. Realm Public Key
The Realm public key claim identifies the attestation key which is
used to sign the Realm token
The value of the Realm public key claim is a byte string
representation of a COSE_Key.
This claim MUST be present in a CCA Realm state attestation token
when the attestation model is not Direct mode.
Compatibility: this claim can be present for all values of CCA Realm
Profile.
cca-realm-public-key-label = 44237
; See RFC8152 for definition of COSE_Key
cca-realm-public-key-type = bstr .cbor COSE_Key
cca-realm-public-key = (
cca-realm-public-key-label => cca-realm-public-key-type
)
4.8.8. Realm Public Key Hash Algorithm ID
The Realm public key hash algorithm identifier claim identifies the
algorithm used to hash the value of the Realm Public Key claim
Section 4.8.7 such that it can be presented as a Challenge for the
bound CCA Platform token Section 4.10.
This claim MUST be present in a CCA Realm state attestation token
when the attestation model is not Direct mode.
Compatibility: this claim can be present for all values of CCA Realm
Profile.
cca-realm-public-key-hash-algo-id-label = 44240
cca-realm-public-key-hash-algo-id = (
cca-realm-public-key-hash-algo-id-label => text
)
4.8.9. Realm MEC Policy
The Realm MEC policy claim identifies the MEC policy of the Realm.
On a platform which does not implement FEAT_MEC, the value of the
Realm MEC policy claim shall be cca-realm-mec-policy-shared.
This claim MUST be present in a CCA Realm state attestation token.
Compatibility: this claim will be present for all values of CCA Realm
Profile.
cca-realm-mec-policy-label = 44243
cca-realm-mec-policy-shared = 0
cca-realm-mec-policy-private = 1
cca-realm-mec-policy = (
cca-realm-mec-policy-label =>
cca-realm-mec-policy-shared /
cca-realm-mec-policy-private
)
4.8.10. Realm LFA Policy
The Realm LFA policy identifies the Live Firmware Activation policy
of the Realm.
This claim is OPTIONAL in a CCA Realm state attestation token.
Compatibility: this claim can be present for all values of CCA Realm
Profile.
cca-realm-lfa-policy-label = 44244
cca-realm-lfa-policy-disallow = 0
cca-realm-lfa-policy-allow = 1
cca-realm-lfa-policy = (
cca-realm-lfa-policy-label =>
cca-realm-lfa-policy-disallow /
cca-realm-lfa-policy-allow
)
4.8.11. Realm Instance ID
The Realm Instance ID claim is a random value generated using a
cryptographic-quality entropy source. This claim distinguishes
otherwise identical Realms.
The claim is identified using the EAT [EAT] ueid label. To
correspond with the ueid RAND type, the first byte of the Realm
Instance ID value must be 0x01.
This claim MUST be present in a CCA Realm state attestation token.
Compatibility: this claim can be present where realm profile values
are at or newer than "tag:arm.com,2024:realm#2.0.0".
cca-realm-instance-id-label = 256 ; EAT ueid
; EAT UEIDs need to be 7 - 33 bytes
cca-realm-instance-id-type = eat-ueid-rand-type
cca-realm-instance-id = (
cca-realm-instance-id-label => cca-realm-instance-id-type
)
4.8.12. Realm Devices Token Hash
The Realm devices token hash claim contains a hash of the CBOR
encoding of cca-realm-devices-token that represents the set of
devices assigned to the Realm.
The Realm devices token hash claim MUST be present in a Realm token
whenever one or more devices are assigned to the Realm. If no
devices are assigned, the claim MUST NOT be present.
Compatibility: this claim can be present where realm profile values
are at or newer than "tag:arm.com,2024:realm#2.0.0".
cca-realm-devices-token-hash-label = 44257
cca-realm-devices-token-hash = (
cca-realm-devices-token-hash-label => arm-platform-hash-type
)
4.9. Device Token
ToDo in separate PR
4.9.1. Selectively Assigned Devices Token
4.9.2. Comprehensive Trust Devices Token
4.10. Token Binding
The reference implementation uses a 'Delegated Model' for token
signing. In this model, the completion of signing operations for the
CCA token is delegated from the CCA Platform RoT to the RMM. When
the RMM initialises, it obtains a 'Realm Attestation Token' (RAK)
signing key pair from the CCA Platform RoT. The public part of that
key pair is hashed and used as a challenge to obtain a CCA Platform
token (signed by the CCA Platform RoT). When guest code in a Realm
requests a CCA Attestation token, the RMM prepares a Realm state
token, signed by the RAK private key, then wraps both tokens in a CMW
Collection. The two tokens are bound together by the Nonce claim in
the CCA Platform token having the same value as a hash of the Realm
Public key claim in the Realm state token (using the hash algorithm
identified by the Realm Public Key Hash Algorithm ID claim).
A verifier MUST check this binding is valid when verifying a CCA
Attestation token.
An implementation may choose instead a 'Direct Model'. In this
model, when guest code in a Realm requests a CCA Attestation token,
the RMM prepares a Realm state claim set, but does not wrap it in a
CMW. Instead, the claim set is hashed and this value is used as a
Challenge to obtain a CCA Platform token, signed by the CCA Platform
RoT. The CCA Platform and Realm state claim set are presented within
a CMW Collection as in the Delegated model. The two parts of the
collection are bound together by the Nonce claim in the CCA Platform
token having the same value as the hash of the Realm state claim set.
If the Direct Model is used, the CCA Platform profile claim
Section 4.5.1 MUST have a different value from the reference profile.
The map value within the CCA Attestation token CMW Collection for the
Realm state claim set MUST also have a different value to that used
for a Realm state CMW token. In such a profile, the Realm Public Key
Section 4.8.7 and Realm Public Key Hash Algorithm ID Section 4.8.8
claims will not be used.
4.11. Reference Profile
4.11.1. Token Encoding and Signing
The CCA attestation token is encoded in CBOR [STD94] format. The
CBOR representation of a CCA attestation token MUST be "valid"
according to the definition in Section 1.2 of [STD94]. Besides, only
definite-length string, arrays, and maps are allowed.
The CCA reference profile is designed to not emit CBOR preferred
serializations (Section 4.1 of [STD94]). This profile assumes that
the Verifier MUST be a variation-tolerant CBOR decoder.
Cryptographic protection is obtained by wrapping the CCA Platform
claims set in a COSE Web Token (CWT) [RFC8392]. The signature
structure MUST be a tagged (18) COSE_Sign1 [STD96]. In the Delegated
and HESRAK attestation models, the Realm claims set will also be
wrapped in a CWT.
Acknowledging the variety of markets, regulations and use cases in
which the CCA attestation token can be used, the baseline profile
does not impose any strong requirement on the cryptographic
algorithms that need to be supported by Attesters and Verifiers. The
flexibility provided by the COSE format should be sufficient to deal
with the level of cryptographic agility needed to adapt to specific
use cases. It is RECOMMENDED that commonly adopted algorithms are
used, such as those discussed in [COSE-ALGS]. It is expected that
receivers will accept a wider range of algorithms, while Attesters
would produce CCA tokens using only one such algorithm.
The CCA Platform token is always directly signed by the CCA Platform
RoT. Therefore, the CCA Platform claims-set is never carried in a
Detached EAT bundle (Section 5 of [EAT]).
4.11.2. Freshness Model
The CCA token supports the freshness models for attestation Evidence
based on nonces and epoch handles (Section 10.2 and Section 10.3 of
[RFC9334]) using the nonce claim to convey the nonce or epoch handle
supplied by the Verifier. No further assumption on the specific
remote attestation protocol is made.
Note that use of epoch handles is constrained by the type
restrictions imposed by the eat_nonce syntax. For use in CCA tokens,
it must be possible to encode the epoch handle as an opaque binary
string between 8 and 64 octets.
Table 2 presents a concise view of the requirements described in the
preceding sections.
+==================+=============================================+
| Issue | Profile Definition |
+==================+=============================================+
| CBOR/JSON | CBOR MUST be used |
+------------------+---------------------------------------------+
| CBOR Encoding | Definite length maps and arrays MUST be |
| | used |
+------------------+---------------------------------------------+
| CBOR Encoding | Definite length strings MUST be used |
+------------------+---------------------------------------------+
| CBOR | Variant serialization MAY be used |
| Serialization | |
+------------------+---------------------------------------------+
| COSE Protection | COSE_Sign1 MUST be used |
+------------------+---------------------------------------------+
| Algorithms | [COSE-ALGS] SHOULD be used |
+------------------+---------------------------------------------+
| Detached EAT | The CCA Claims set SHOULD not be carried in |
| Bundle Usage | a Detached EAT bundle |
+------------------+---------------------------------------------+
| Verification Key | Any identification method listed in |
| Identification | Appendix F.1 of [EAT] |
+------------------+---------------------------------------------+
| Endorsements | See Section 7.3 |
+------------------+---------------------------------------------+
| Freshness | nonce or epoch ID based |
+------------------+---------------------------------------------+
| Claims | Those defined in Section 4. As per general |
| | EAT rules, the receiver MUST NOT error out |
| | on claims it does not understand. |
+------------------+---------------------------------------------+
Table 2: Baseline Profile
5. Collated CDDL
=============== NOTE: '\' line wrapping per RFC 8792 ================
cca-token = #6.907(cca-token-cmw)
eat-cwt-coap-cf = 263
cca-token-cmw = {
0xACCA => [
eat-cwt-coap-cf,
bytes .cbor COSE_Sign1<arm-platform-claims>,
],
0xACD1 => [
eat-cwt-coap-cf,
bytes .cbor COSE_Sign1<cca-realm-claims>,
],
}
COSE_Sign1<C> = #6.18([
Headers,
payload: bytes .cbor C,
signature: bytes,
])
cca-realm-claims = cca-realm-claim-map
cca-realm-claim-map = {
cca-realm-challenge,
? cca-realm-profile,
cca-realm-instance-id,
cca-realm-personalization-value,
cca-realm-initial-measurement,
cca-realm-extensible-measurements,
cca-realm-hash-algo-id,
cca-realm-public-key,
cca-realm-public-key-hash-algo-id,
cca-realm-mec-policy,
? cca-realm-lfa-policy,
? cca-realm-devices-token-hash,
}
cca-realm-challenge-label = 10
cca-realm-challenge-type = bytes .size 64
cca-realm-challenge = (cca-realm-challenge-label => cca-realm-\
challenge-type)
cca-realm-extensible-measurements-label = 44239
cca-realm-extensible-measurements = (cca-realm-extensible-\
measurements-label => [4*4cca-realm-measurement-type])
cca-realm-hash-algo-id-label = 44236
cca-realm-hash-algo-id = (cca-realm-hash-algo-id-label => text)
cca-realm-initial-measurement-label = 44238
cca-realm-initial-measurement = (cca-realm-initial-measurement-\
label => cca-realm-measurement-type)
cca-realm-measurement-type = bytes .size 32 / bytes .size 48 / \
bytes .size 64
cca-realm-personalization-value-label = 44235
cca-realm-personalization-value-type = bytes .size 64
cca-realm-personalization-value = (cca-realm-personalization-value-\
label => cca-realm-personalization-value-type)
cca-realm-profile-label = 265
cca-realm-profile-type = "tag:arm.com,2026:realm#2.0.0"
cca-realm-profile = (cca-realm-profile-label => cca-realm-profile-\
type)
cca-realm-public-key-hash-algo-id-label = 44240
cca-realm-public-key-hash-algo-id = (cca-realm-public-key-hash-algo-\
id-label => text)
cca-realm-public-key-label = 44237
cca-realm-public-key-type = bstr .cbor COSE_Key
cca-realm-public-key = (cca-realm-public-key-label => cca-realm-\
public-key-type)
cca-realm-mec-policy-label = 44243
cca-realm-mec-policy-shared = 0
cca-realm-mec-policy-private = 1
cca-realm-mec-policy = (cca-realm-mec-policy-label => cca-realm-mec-\
policy-shared / cca-realm-mec-policy-private)
cca-realm-lfa-policy-label = 44244
cca-realm-lfa-policy-disallow = 0
cca-realm-lfa-policy-allow = 1
cca-realm-lfa-policy = (cca-realm-lfa-policy-label => cca-realm-lfa-\
policy-disallow / cca-realm-lfa-policy-allow)
cca-realm-instance-id-label = 256
cca-realm-instance-id-type = eat-ueid-rand-type
cca-realm-instance-id = (cca-realm-instance-id-label => cca-realm-\
instance-id-type)
cca-realm-devices-token-hash-label = 44257
cca-realm-devices-token-hash = (cca-realm-devices-token-hash-label =\
> arm-platform-hash-type)
label = int / tstr
values = any
COSE_Key = {
1 => tstr / int,
? 2 => bstr,
? 3 => tstr / int,
? 4 => [+ tstr / int],
? 5 => bstr,
* label => values,
}
arm-platform-hash-type = bytes .size 32 / bytes .size 48 / bytes .\
size 64
eat-ueid-rand-type = bytes .join eat-ueid-rand-fmt
eat-ueid-rand-fmt = [
ueid-rand-typ,
bytes .size 32,
]
ueid-rand-typ = h'01'
arm-platform-claims = arm-platform-claim-map
arm-platform-claim-map = {
arm-platform-profile,
? arm-platform-challenge,
arm-platform-workload-binding,
arm-platform-implementation-id,
arm-platform-instance-id,
arm-platform-config,
arm-platform-lifecycle,
arm-platform-sw-components,
? arm-platform-verification-service,
arm-platform-hash-algo-id,
arm-platform-client-id,
? arm-platform-manufacturing-config,
? arm-platform-extension,
? arm-platform-peer-signers,
? arm-platform-tbb-rotpk,
? arm-platform-discrete-tpm-binding-data,
}
arm-platform-workload-binding-label = 2408
arm-platform-workload-binding = (arm-platform-workload-binding-\
label => arm-platform-hash-type)
arm-platform-challenge-label = 10
arm-platform-challenge = (arm-platform-challenge-label => arm-\
platform-hash-type)
arm-platform-config-label = 2401
arm-platform-config-type = bytes
arm-platform-config = (arm-platform-config-label => arm-platform-\
config-type)
arm-platform-hash-algo-id-label = 2402
arm-platform-hash-algo-id = (arm-platform-hash-algo-id-label => text)
arm-platform-implementation-id-label = 2396
arm-platform-implementation-id-type = bytes .size 32
arm-platform-implementation-id = (arm-platform-implementation-id-\
label => arm-platform-implementation-id-type)
arm-platform-instance-id-label = 256
arm-platform-instance-id-type = eat-ueid-rand-type
arm-platform-instance-id = (arm-platform-instance-id-label => arm-\
platform-instance-id-type)
arm-platform-profile-label = 265
arm-platform-profile-type = "tag:arm.com,2026:cca_platform#2.0.0" / \
"tag:arm.com,2026:cca_platform#2.0.0;delegated" / "tag:arm.com,2026:\
cca_platform#2.0.0;HESRAK" / "tag:arm.com,2026:cca_platform#2.0.0;\
direct" / "tag:arm.com,2026:cca_platform#2.1.0" / "tag:arm.com,2026:\
cca_platform#2.1.0;delegated" / "tag:arm.com,2026:cca_platform#2.1.0\
;HESRAK" / "tag:arm.com,2026:cca_platform#2.1.0;direct"
arm-platform-profile = (arm-platform-profile-label => arm-platform-\
profile-type)
arm-platform-lifecycle-label = 2395
arm-platform-lifecycle-unknown-type = 0x0000 .. 0x00ff
arm-platform-lifecycle-assembly-and-test-type = 0x1000 .. 0x10ff
arm-platform-lifecycle-platform-rot-provisioning-type = 0x2000 .. \
0x20ff
arm-platform-lifecycle-secured-type = 0x3000 .. 0x30ff
arm-platform-lifecycle-non-platform-rot-debug-type = 0x4000 .. 0x40ff
arm-platform-lifecycle-recoverable-platform-rot-debug-type = 0x5000 \
.. 0x50ff
arm-platform-lifecycle-decommissioned-type = 0x6000 .. 0x60ff
arm-platform-lifecycle-type = arm-platform-lifecycle-unknown-type / \
arm-platform-lifecycle-assembly-and-test-type / arm-platform-\
lifecycle-platform-rot-provisioning-type / arm-platform-lifecycle-\
secured-type / arm-platform-lifecycle-non-platform-rot-debug-type / \
arm-platform-lifecycle-recoverable-platform-rot-debug-type / arm-\
platform-lifecycle-decommissioned-type
arm-platform-lifecycle = (arm-platform-lifecycle-label => arm-\
platform-lifecycle-type)
arm-platform-sw-components-label = 2399
arm-platform-sw-component = {
? 1 => text,
2 => arm-platform-hash-type,
? 4 => text,
5 => arm-platform-hash-type,
? 6 => text,
? 7 => bool,
? 8 => [+ arm-platform-hash-type],
}
arm-platform-sw-components = (arm-platform-sw-components-label => [\
+ arm-platform-sw-component])
arm-platform-verification-service-label = 2400
arm-platform-verification-service-type = text
arm-platform-verification-service = (arm-platform-verification-\
service-label => arm-platform-verification-service-type)
arm-platform-client-id-label = 2394
arm-platform-client-id-rmsd = 1
arm-platform-client-id-type = arm-platform-client-id-rmsd
arm-platform-client-id = (arm-platform-client-id-label => arm-\
platform-client-id-type)
arm-platform-manufacturing-config-label = 2403
arm-platform-manufacturing-config-type = bytes
arm-platform-manufacturing-config = (arm-platform-manufacturing-\
config-label => arm-platform-manufacturing-config-type)
arm-platform-extension-label = 2404
$protocols-support-vca /= "spdm-1.2.0" / "spdm-1.2.1" / "spdm-1.2.2\
" / "spdm-1.2.3" / "spdm-1.3.0" / "spdm-1.3.1" / "spdm-1.3.2" / "\
spdm-1.4.0"
$type-with-encryption /= "cxl-type-3"
encryption-type = (
host-side-encryption: 0,
target-side-encryption: 1,
no-encryption: 2,
)
arm-platform-extension-device-common = (
? 1 => text,
2 => arm-platform-hash-type,
3 => arm-platform-hash-type,
4 => bool,
)
arm-platform-extension-device = {
arm-platform-extension-device-common,
((
5 => $protocols-support-vca,
6 => arm-platform-hash-type,
) // 5 => text),
((
7 => $type-with-encryption,
8 => &encryption-type,
) // 7 => text),
}
arm-platform-extension = (arm-platform-extension-label => [+ arm-\
platform-extension-device])
arm-platform-peer-signers-label = 2406
arm-platform-peer-signers-type = [+ bytes]
arm-platform-peer-signers = (arm-platform-peer-signers-label => arm-\
platform-peer-signers-type)
arm-platform-tbb-rotpk-label = 2405
arm-platform-tbb-rotpk-type = [+ arm-platform-tbb-rotpk-item]
arm-platform-tbb-rotpk-item = {
1 => tstr,
2 => int,
3 => int,
4 => arm-platform-hash-type,
}
arm-platform-tbb-rotpk = (arm-platform-tbb-rotpk-label => arm-\
platform-tbb-rotpk-type)
arm-platform-discrete-tpm-binding-data-label = 2407
arm-platform-discrete-tpm-binding-data-type = bytes
arm-platform-discrete-tpm-binding-data = (arm-platform-discrete-tpm-\
binding-data-label => arm-platform-discrete-tpm-binding-data-type)
Headers = (
protected: empty_or_serialized_map,
unprotected: header_map,
)
empty_or_serialized_map = bstr .cbor header_map / bstr .size 0
header_map = {
Generic_Headers,
* label => values,
}
Generic_Headers = (
? 1 => int / tstr,
? 2 => [+ label],
? 3 => tstr / int,
? 4 => bstr,
? (5 => bstr // 6 => bstr),
)
6. Signing key implementation alternatives
In the CCA Platform reference design, PAKs (Section 3.4, Paragraph 2)
are raw public keys.
Some implementations may choose to use a PAK that is a certified
public key. If this option is taken, the value of the CCA Platform
Profile Definition claim Section 4.5.1 MUST be altered from the
reference implementation value.
Where the implementation uses a CPAK that is endorsed via an X.509
certificate chain, the endorsement artefacts can be included in the
COSE_Sign1 envelope of the CCA platform token using parameters from
CBOR Object Signing and Encryption (COSE) Header Parameters for
Carrying and Referencing X.509 Certificates [COSE-X509]. It is
recommended that this is done as follows:
* The CPAK certificate is identified by including an x5t thumbprint
parameter in the COSE_Sign1 protected header.
* The CPAK certificate itself is then packaged within an x5chain
parameter in the COSE_Sign1 unprotected header.
* This x5chain parameter can also include other certificates that
endorse the CPAK certificate.
Alternatively, the other certificates in the chain that endorses the
CPAK certificate can be packaged in an additional entry within the
RATS Conceptual Messages Wrapper [CMW] token
7. CCA Attestation Token Verification
To verify the token for the reference profile, the initial need is to
check correct encoding for the token. Primary trust is established
by checking the signing of the CCA Platform token CWT. The key used
for verification is supplied to the Verifier by an authorized
Endorser along with the corresponding Attester's Implementation ID
and Instance ID. For the verifier, this ID information claim is used
to assist locating the key used to verify the signature covering the
CCA Platform CWT token. The verifier can also be supplied with the
information that the key instance has been revoked and is no longer
valid.
If an implementation has chosen to endorse the CPAK via an X.509
certificate chain, the ID claims may not be required to verify the
CPAK. Instead this is achieved by forming a full X.509 chain to the
trusted Certificate Authority root and validating that chain.
Additional validation checks on the token are:
* Checking that the binding between the CCA Platform token and the
Realm state token is valid Section 4.10. This has the side effect
of establishing the trustworthiness of the RAK public key.
* Validating that the Realm state token is correctly signed by the
RAK.
* Checking that the value of the Section 4.5.2 claim is cca-
platform-lifecycle-secured state. Note that some other values of
this claim (cca-platform-lifecycle-non-psa-rot-debug and cca-
platform-lifecycle-recoverable-psa-rot states) may indicate that
the attester is only temporarily unsuitable and the verifier may
choose the to indicate this as a contraindication rather than a
full verification failure. See discussion of the CCA platform
lifecycle in [RMM].
The Verifier will typically operate a policy where values of some of
the claims in this profile can be compared to reference values,
registered with the Verifier for a given deployment, in order to
confirm that the device is endorsed by the manufacturer supply chain.
The policy may require that the relevant claims must have a match to
a registered reference value. All claims may be worthy of additional
appraisal. It is likely that most deployments would include a policy
with appraisal for the following claims:
* Implementation ID - the value of the Implementation ID can be used
to identify the verification requirements of the deployment.
* Software Component, Measurement Value - this value can uniquely
identify a firmware release from the supply chain. In some cases,
a Verifier may maintain a record for a series of firmware
releases, being patches to an original baseline release. A
verification policy may then allow this value to match any point
on that release sequence or expect some minimum level of maturity
related to the sequence.
* Software Component, Signer ID - where present in a deployment,
this could allow a Verifier to operate a more general policy than
that for Measurement Value as above, by allowing a token to
contain any firmware entries signed by a known Signer ID, without
checking for a uniquely registered version.
7.1. Live Firmware Activation (LFA)
ToDo in separate PR
7.2. AR4SI Trustworthiness Claims Mappings
[RATS-AR4SI] defines an information model that Verifiers can employ
to produce Attestation Results. AR4SI provides a set of standardized
appraisal categories and tiers that greatly simplifies the task of
writing Relying Party policies in multi-attester environments.
The contents of Table 3 are intended as guidance for implementing a
PSA Verifier that computes its results using AR4SI. The table
describes which PSA Evidence claims (if any) are related to which
AR4SI trustworthiness claim, and therefore what the Verifier must
consider when deciding if and how to appraise a certain feature
associated with the PSA Attester.
TODO: Ar4SI
+===================+=============================================+
| Trustworthiness | Related PSA claims |
| Vector claims | |
+===================+=============================================+
| configuration | Software Components (Section 4.6.1) |
+-------------------+---------------------------------------------+
| executables | ditto |
+-------------------+---------------------------------------------+
| file-system | N/A |
+-------------------+---------------------------------------------+
| hardware | Implementation ID (Section 4.4.2) and CCA |
| | Platform config (TODO) |
+-------------------+---------------------------------------------+
| instance-identity | Instance ID (Section 4.4.1). The Security |
| | Lifecycle (Section 4.5.2) can also impact |
| | the derived identity. |
+-------------------+---------------------------------------------+
| runtime-opaque | Indirectly derived from executables, |
| | hardware, and instance-identity. The |
| | Security Lifecycle (Section 4.5.2) can also |
| | be relevant: for example, any debug state |
| | will expose otherwise protected memory. |
+-------------------+---------------------------------------------+
| sourced-data | N/A |
+-------------------+---------------------------------------------+
| storage-opaque | Indirectly derived from executables, |
| | hardware, and instance-identity. |
+-------------------+---------------------------------------------+
Table 3: AR4SI Claims mappings
This document does not prescribe what value must be chosen based on
each possible situation: when assigning specific Trustworthiness
Claim values, an implementation is expected to follow the algorithm
described in Section 2.3.3 of [RATS-AR4SI].
7.3. Endorsements, Reference Values and Verification Key Material
The [CCA-ENDORSEMENTS] defines a protocol based on the [RATS-CoRIM]
data model that can be used to convey CCA Endorsements, Reference
Values and Verification Key Material to the Verifier.
8. Implementation Status
// RFC Editor: please remove this section before publication.
Implementations of this specification are provided by the Trusted
Firmware-RMM project [TF-RMM] and the Veraison project [Veraison].
These implementations are released as open-source software.
9. Security and Privacy Considerations
This specification re-uses the EAT specification and therefore the
CWT specification. Hence, the security and privacy considerations of
those specifications apply here as well.
Attestation tokens contain information that may be unique to a device
and therefore they may allow singling out an individual device for
tracking purposes. Deployments that have privacy requirements must
take appropriate measures to ensure that the token is only used to
provision anonymous/pseudonym keys.
10. IANA Considerations
TODO: additional top level claims
10.1. CBOR Web Token Claims Registration
IANA is requested to make permanent the following claims that have
been assigned via early allocation in the "CBOR Web Token (CWT)
Claims" registry [IANA-CWT].
10.1.1. Arm CCA Attestation CMW
* Claim Name: arm-cca-attestation-cmw
* Claim Description: Arm CCA Attestation CMW
* JWT Claim Name: N/A
* Claim Key: 907
* Claim Value Type(s): map
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.1 of RFCthis
10.1.2. Security Lifecycle Claim
* Claim Name: arm-platform-security-lifecycle
* Claim Description: Arm Platform Security Lifecycle
* JWT Claim Name: N/A
* Claim Key: 2395
* Claim Value Type(s): unsigned integer
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.5.2 of RFCthis
10.1.3. Implementation ID Claim
* Claim Name: arm-platform-implementation-id
* Claim Description: Arm Platform Implementation ID
* JWT Claim Name: N/A
* Claim Key: 2396
* Claim Value Type(s): byte string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.4.2 of RFCthis
10.1.4. Software Components Claim
* Claim Name: arm-platform-software-components
* Claim Description: Arm Platform Software Components
* JWT Claim Name: N/A
* Claim Key: 2399
* Claim Value Type(s): array
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.6.1 of RFCthis
10.1.5. Verification Service Indicator Claim
* Claim Name: arm-platform-verification-service-indicator
* Claim Description: Arm Platform Verification Service Indicator
* JWT Claim Name: N/A
* Claim Key: 2400
* Claim Value Type(s): text string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.7.1 of RFCthis
10.1.6. Platform Config Claim
* Claim Name: arm-platform-config
* Claim Description: Arm Platform Configuration
* JWT Claim Name: N/A
* Claim Key: 2401
* Claim Value Type(s): byte string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.5.3 of RFCthis
10.1.7. Platform Hash Algorithm ID Claim
* Claim Name: arm-platform-hash-algm-id
* Claim Description: Arm Platform Hash Algorithm ID
* JWT Claim Name: N/A
* Claim Key: 2402
* Claim Value Type(s): text string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.6.2 of RFCthis
10.1.8. Platform Manufacturing Config
* Claim Name: arm-platform-manufacturing-config
* Claim Description: Arm Platform Manufacturing Config
* JWT Claim Name: N/A
* Claim Key: 2403
* Claim Value Type(s): byte string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.6.4 of RFCthis
10.1.9. Platform Extension
* Claim Name: arm-platform-extension
* Claim Description: Arm Platform Extension
* JWT Claim Name: N/A
* Claim Key: 2404
* Claim Value Type(s): array
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.6.5 of RFCthis
10.1.10. Platform TBB RoTPK
* Claim Name: arm-platform-tbb-rotpk
* Claim Description: Arm Platform TBB RoTPK
* JWT Claim Name: N/A
* Claim Key: 2405
* Claim Value Type(s): array
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.6.8 of RFCthis
10.1.11. Platform Peer Signers
* Claim Name: arm-platform-peer-signers
* Claim Description: Arm Platform Peer Signers
* JWT Claim Name: N/A
* Claim Key: 2406
* Claim Value Type(s): array
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.6.6 of RFCthis
10.1.12. Platform Device TPM Binding Data
* Claim Name: arm-platform-discrete-tpm-binding-data
* Claim Description: Arm Platform Device TPM Binding Data
* JWT Claim Name: N/A
* Claim Key: 2407
* Claim Value Type(s): byte string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.6.7 of RFCthis
10.1.13. Platform Workload Binding
* Claim Name: arm-platform-workload-binding
* Claim Description: Arm Platform Workload Binding
* JWT Claim Name: N/A
* Claim Key: 2408
* Claim Value Type(s): byte string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.3.1 of RFCthis
10.1.14. CCA Token Platform Token Label
* Claim Name: cca-platform-token-label
* Claim Description: CCA Token Platform Token Label
* JWT Claim Name: N/A
* Claim Key: 44234
* Claim Value Type(s): byte string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.1 of RFCthis
10.1.15. Realm Personalization Value Claim
* Claim Name: cca-realm-personalization-value
* Claim Description: CCA Realm Personalisation Value
* JWT Claim Name: N/A
* Claim Key: 44235
* Claim Value Type(s): byte string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.8.3 of RFCthis
10.1.16. Realm Hash Algorithm ID Claim
* Claim Name: cca-realm-hash-algm-id
* Claim Description: CCA Realm Hash Algorithm ID
* JWT Claim Name: N/A
* Claim Key: 44236
* Claim Value Type(s): text string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.8.6 of RFCthis
10.1.17. Realm Public Key Claim
* Claim Name: cca-realm-public-key
* Claim Description: CCA Realm Public Key
* JWT Claim Name: N/A
* Claim Key: 44237
* Claim Value Type(s): byte string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.8.7 of RFCthis
10.1.18. Realm Initial Measurement Claim
* Claim Name: cca-realm-initial-measurement
* Claim Description: CCA Realm Initial Measurement
* JWT Claim Name: N/A
* Claim Key: 44238
* Claim Value Type(s): byte string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.8.4 of RFCthis
10.1.19. Realm Extensible Measurements Claim
* Claim Name: cca-realm-extensible-measurements
* Claim Description: CCA Realm Extensible Measurements
* JWT Claim Name: N/A
* Claim Key: 44239
* Claim Value Type(s): array
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.8.4 of RFCthis
10.1.20. Realm Public Key Hash Algorithm ID Claim
* Claim Name: cca-realm-public-key-hash-algm-id
* Claim Description: Realm Public Key Hash Algorithm ID Claim
* JWT Claim Name: N/A
* Claim Key: 44240
* Claim Value Type(s): text string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.8.8 of RFCthis
10.1.21. Realm MEC Policy
* Claim Name: cca-realm-mec-policy
* Claim Description: Realm MEC Policy
* JWT Claim Name: N/A
* Claim Key: 44243
* Claim Value Type(s): unsigned integer
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.8.9 of RFCthis
10.1.22. Realm LFA Policy
* Claim Name: cca-realm-lfa-policy
* Claim Description: Realm LFA Policy
* JWT Claim Name: N/A
* Claim Key: 44244
* Claim Value Type(s): unsigned integer
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.8.10 of RFCthis
10.1.23. Realm Devices Token Hash
* Claim Name: cca-realm-devices-token-hash
* Claim Description: Realm Devices Token Hash
* JWT Claim Name: N/A
* Claim Key: 44257
* Claim Value Type(s): byte string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.8.12 of RFCthis
10.1.24. CCA Token Delegated Realm Token Label
* Claim Name: cca-platform-delegated-realm-label
* Claim Description: CCA Token Platform Token Label
* JWT Claim Name: N/A
* Claim Key: 44241
* Claim Value Type(s): byte string
* Change Controller: iana-request@arm.com
* Specification Document(s): Section 4.1 of RFCthis
10.2. Media Types
No new media type registration is requested. To indicate that the
transmitted content is a CCA attestation token, applications can use
the application/eat+cwt media type defined in [EAT-MEDIATYPES] with
the eat_profile parameter set to tag:arm.com,2023:cca_platform#1.0.0.
10.3. CoAP Content-Formats Registration
IANA is requested to register a CoAP Content-Format ID in the "CoAP
Content-Formats" registry [IANA-CoAP-Content-Formats]:
* A registration for the application/eat+cwt media type with the
eat_profile parameter equal to
"tag:arm.com,2023:cca_platform#1.0.0"
The Content-Formats should be allocated from the Expert review range
(0-255).
10.3.1. Registry Contents
* Media Type: `application/eat+cwt;
eat_profile="tag:arm.com,2023:cca_platform#1.0.0"
* Encoding: -
* Id: To-be-assigned by IANA
* Reference: RFCthis
* Media Type: `application/eat+cwt;
eat_profile="tag:arm.com,2023:realm#1.0.0"
* Encoding: -
* Id: To-be-assigned by IANA
* Reference: RFCthis
11. References
11.1. Normative References
[CCA-ARCH] Arm, "Learn the architecture - Introducing Arm
Confidential Compute Architecture", 19 March 2025,
<https://developer.arm.com/documentation/den0125/400>.
[CMW] Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and
D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work
in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-23,
11 December 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-msg-wrap-23>.
[COSE-ALGS]
"*** BROKEN REFERENCE ***".
[EAT] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-31, 6
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-eat-31>.
[EAT-MEDIATYPES]
Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media
Types", Work in Progress, Internet-Draft, draft-ietf-rats-
eat-media-type-12, 3 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
eat-media-type-12>.
[IANA-CWT] IANA, "CBOR Web Token (CWT) Claims", 2022,
<https://www.iana.org/assignments/cwt/cwt.xhtml#claims-
registry>.
[IANA.named-information]
IANA, "Named Information",
<https://www.iana.org/assignments/named-information>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RME] Arm, "Learn the architecture - Realm Management
Extension", 26 September 2025,
<https://developer.arm.com/documentation/den0126/0102>.
[RME-SYSARCH]
Arm, "Arm Realm Management Extension (RME) System
Architecture", 15 December 2025,
<https://developer.arm.com/documentation/den0129/ca>.
[RMM] Arm, "Realm Management Monitor specification 2.0", 3
August 2026,
<https://developer.arm.com/documentation/den0137/2-0bet3>.
[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[TBB] Arm, "Trusted Board Boot", 30 December 2024,
<https://trustedfirmware-
a.readthedocs.io/en/stable/design/trusted-board-
boot.html>.
11.2. Informative References
[CCA-ENDORSEMENTS]
Deshpande, Y. and T. Fossati, "A CoRIM Profile for Arm's
Confidential Computing Architecture (CCA) Endorsements",
Work in Progress, Internet-Draft, draft-ydb-rats-cca-
endorsements-04, 26 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ydb-rats-cca-
endorsements-04>.
[COSE-X509]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header Parameters for Carrying and Referencing X.509
Certificates", RFC 9360, DOI 10.17487/RFC9360, February
2023, <https://www.rfc-editor.org/rfc/rfc9360>.
[I-D.kdyxy-rats-tdx-eat-profile]
Kostal, G., Dittakavi, S., Yeluri, R., Xia, H., and J. Yu,
"EAT profile for Intel(r) Trust Domain Extensions (TDX)
attestation result", Work in Progress, Internet-Draft,
draft-kdyxy-rats-tdx-eat-profile-02, 13 December 2024,
<https://datatracker.ietf.org/doc/html/draft-kdyxy-rats-
tdx-eat-profile-02>.
[I-D.mandyam-rats-qwestoken]
Mandyam, G., Sekhar, V., and S. Mohammed, "The Qualcomm
Wireless Edge Services (QWES) Attestation Token", Work in
Progress, Internet-Draft, draft-mandyam-rats-qwestoken-00,
1 November 2019, <https://datatracker.ietf.org/doc/html/
draft-mandyam-rats-qwestoken-00>.
[IANA-CoAP-Content-Formats]
IANA, "CoAP Content-Formats", 2022,
<https://www.iana.org/assignments/core-parameters>.
[RATS-AR4SI]
Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
Scarlata, "Attestation Results for Secure Interactions",
Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
10, 18 May 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-ar4si-10>.
[RATS-CoRIM]
Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
W. Pan, "Concise Reference Integrity Manifest", Work in
Progress, Internet-Draft, draft-ietf-rats-corim-11, 6 July
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
rats-corim-11>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[TF-RMM] Trusted Firmware Project, "Trusted Firmware-RMM", 2022,
<https://www.trustedfirmware.org/projects/tf-rmm>.
[Veraison] The Veraison Project, "Veraison ccatoken package", 2022,
<https://github.com/veraison/ccatoken>.
The following examples show CCA attestation tokens for an
hypothetical system comprising a single number of software component.
The attesting device is in a lifecycle state (Section 4.5.2) of
SECURED.
A.1. Delegated Mode
The following sample claim set and token are representative of a CCA
Token using "delegated mode" described in Section 3.2.
In this model, the eat_nonce claim in the Platform token contains a
hash of the RAK public key claim in the Realm token.
A.1.1. Platform Claims Set
The CCA Platform claims set is
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
265:"tag:arm.com,2026:cca_platform#2.0.0",
2408:h'\
0D22E08A98469058486318283489BDB36F09DBEFEB1864DF433FA6E54EA2D711',
2396:h'\
7F454C4602010100000000000000000003003E00010000005058000000000000',
256:h'\
0107060504030201000F0E0D0C0B0A090817161514131211101F1E1D1C1B1A1918',
2401:h'CFCFCFCF',
2395:12291,
2402:"sha-256",
2400:"https://veraison.example/.well-known/veraison/verification",
2394: 1,
2399:[
{
1:"RSE_BL1_2",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
9A271F2A916B0B6EE6CECB2426F0B3206EF074578BE55D9BC94F6F3FE3AB86AA',
6:"sha-256"
},
{
1:"RSE_BL2",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
53C234E5E8472B6AC51C1AE1CAB3FE06FAD053BEB8EBFD8977B010655BFDD3C3',
6:"sha-256"
},
{
1:"RSE_S",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
1121CFCCD5913F0A63FEC40A6FFD44EA64F9DC135C66634BA001D10BCF4302A2',
6:"sha-256"
},
{
1:"AP_BL1",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
1571B5EC78BD68512BF7830BB6A2A44B2047C7DF57BCE79EB8A1C0E5BEA0A501',
6:"sha-256"
},
{
1:"AP_BL2",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
10159BAF262B43A92D95DB59DAE1F72C645127301661E0A3CE4E38B295A97C58',
6:"sha-256"
},
{
1:"SCP_BL1",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
10122E856B3FCD49F063636317476149CB730A1AA1CFAAD818552B72F56D6F68',
6:"sha-256"
},
{
1:"SCP_BL2",
5:h'\
F14B4987904BCB5814E4459A057ED4D20F58A633152288A761214DCD28780B56',
2:h'\
AA67A169B0BBA217AA0AA88A65346920C84C42447C36BA5F7EA65F422C1FE5D8',
6:"sha-256"
},
{
1:"AP_BL31",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
2E6D31A5983A91251BFAE5AEFA1C0A19D8BA3CF601D0E8A706B4CFA9661A6B8A',
6:"sha-256"
},
{
1:"RMM",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
A1FB50E6C86FAE1679EF3351296FD6713411A08CF8DD1790A4FD05FAE8688164',
6:"sha-256"
},
{
1:"HW_CONFIG",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
1A252402972F6057FA53CC172B52B9FFCA698E18311FACD0F3B06ECAAEF79E17',
6:"sha-256"
},
{
1:"FW_CONFIG",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
9A92ADBC0CEE38EF658C71CE1B1BF8C65668F166BFB213644C895CCB1AD07A25',
6:"sha-256"
},
{
1:"TB_FW_CONFIG",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
238903180CC104EC2C5D8B3F20C5BC61B389EC0A967DF8CC208CDC7CD454174F',
6:"sha-256"
},
{
1:"SOC_FW_CONFIG",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
E6C21E8D260FE71882DEBDB339D2402A2CA7648529BC2303F48649BCE0380017',
6:"sha-256"
}
]
}
A.1.2. Realm Claims Set
The CCA Realm claims set is
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
265: "tag:arm.com,2026:realm#2.0.0", / eat_profile /
10: h'\
6E86D6D97CC713BC6DD43DBCE491A6B40311C027A8BF85A39DA63E9CE44C132A8A11\
9D296FAE6A6999E9BF3E4471B0CE01245D889424C31E89793B3B1D6B1504', / \
eat_nonce /
44236: "sha-256", / Realm hash algorithm /
44240: "sha-256", / RAK hash algorithm /
44235: h'\
54686520717569636B2062726F776E20666F78206A756D7073206F76657220313320\
6C617A7920646F67732E54686520717569636B2062726F776E20666F7820', / PV /
44237: << { / RAK /
1: 2, / kty=EC2 /
-1: 2, / crv=P-384 /
-2: h'\
76F988091BE585ED41801AECFAB858548C63057E16B0E676120BBD0D2F9C29E056C5\
D41A0130EB9C21517899DC23146B', / x-coordinate /
-3: h'\
28E1B062BD3EA4B315FD219F1CBB528CB6E74CA49BE16773734F61A1CA61031B2BBF\
3D918F2F94FFC4228E50919544AE' / y-coordinate /
} >>,
44238: h'\
311314AB73620350CF758834AE5C65D9E8C2DC7FEBE6E7D9654BBE864E300D49', \
/ RIM /
44239: [
h'\
24D5B0A296CC05CBD8068C5067C5BD473B770DDA6AE082FE3BA30ABE3F9A6AB1', \
/ REM[0] /
h'\
788FC090BFC6B8ED903152BA8414E73DAF5B8C7BB1E79AD502AB0699B659ED16', \
/ REM[1] /
h'\
DAC46A58415DC3A00D7A741852008E9CAE64F52D03B9F76D76F4B3644FEFC416', \
/ REM[2] /
h'\
32C6AFC627E55585C03155359F331A0E225F6840DB947DD96EFAB81BE2671939' \
/ REM[3] /
],
44243: 1, / MEC policy /
256: h'\
013333333333333333333333333333333333333333333333333333333333333333\
' / Instance ID /
}
A.1.3. Platform Attestation Key
The COSE Key representation of the Platform Attestation Key (PAK)
used for creating the COSE Sign1 signature over the CCA Platform
token is
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
/ kty / 1: 2, / EC2 /
/ crv / -1: 2, / P-384 /
/ x-coordinate / -2: h'\
212867C52E2B9508B0A420A90560F394D2DFAA21BDD7514FF1A901AFE7E1F78BB11D\
4E66F8A8A38AFA76AF6A31C4DE8C',
/ y-coordinate / -3: h'\
84CE2DAFC9964258B53FAD718774F45620D111B176E8318E1187DB0235A318D37BA5\
97FEE80E0E4C762A12BCB3EA6ED4',
/ private key / -4: h'\
8AC090C995869F61AC1358F02B021A26AB6EB386203AC735D7CE9855538B91F74C44\
B0D580243EFB799A293DCBAA0899'
}
A.1.4. Realm Attestation Key
The COSE Key representation of the Realm Attestation Key (RAK) used
for creating the COSE Sign1 signature over the CCA Realm token is
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
/ kty / 1: 2, / EC2 /
/ crv / -1: 2, / P-384 /
/ x-coordinate / -2: h'\
76F988091BE585ED41801AECFAB858548C63057E16B0E676120BBD0D2F9C29E056C5\
D41A0130EB9C21517899DC23146B',
/ y-coordinate / -3: h'\
28E1B062BD3EA4B315FD219F1CBB528CB6E74CA49BE16773734F61A1CA61031B2BBF\
3D918F2F94FFC4228E50919544AE',
/ private key / -4: h'\
2011C7F03CEE4325176E524F033C0CE1E21A76E6C1A4F0B839AA1DF61E0E8A5C8A05\
740F9B69EFA7EB1A4185BD117F68'
}
A.1.5. Signed and Bound Assembly
The resulting CMW collection is
=============== NOTE: '\' line wrapping per RFC 8792 ================
907({
44234: [
263,
<< 18([
h'A1013822',
{},
<< {
265:"tag:arm.com,2026:cca_platform#2.0.0",
2408:h'\
0D22E08A98469058486318283489BDB36F09DBEFEB1864DF433FA6E54EA2D711',
2396:h'\
7F454C4602010100000000000000000003003E00010000005058000000000000',
256:h'\
0107060504030201000F0E0D0C0B0A090817161514131211101F1E1D1C1B1A1918',
2401:h'CFCFCFCF',
2395:12291,
2402:"sha-256",
2394: 1,
2400:"https://veraison.example/.well-known/veraison/\
verification",
2399:[
{
1:"RSE_BL1_2",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
9A271F2A916B0B6EE6CECB2426F0B3206EF074578BE55D9BC94F6F3FE3AB86AA',
6:"sha-256"
},
{
1:"RSE_BL2",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
53C234E5E8472B6AC51C1AE1CAB3FE06FAD053BEB8EBFD8977B010655BFDD3C3',
6:"sha-256"
},
{
1:"RSE_S",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
1121CFCCD5913F0A63FEC40A6FFD44EA64F9DC135C66634BA001D10BCF4302A2',
6:"sha-256"
},
{
1:"AP_BL1",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
1571B5EC78BD68512BF7830BB6A2A44B2047C7DF57BCE79EB8A1C0E5BEA0A501',
6:"sha-256"
},
{
1:"AP_BL2",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
10159BAF262B43A92D95DB59DAE1F72C645127301661E0A3CE4E38B295A97C58',
6:"sha-256"
},
{
1:"SCP_BL1",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
10122E856B3FCD49F063636317476149CB730A1AA1CFAAD818552B72F56D6F68',
6:"sha-256"
},
{
1:"SCP_BL2",
5:h'\
F14B4987904BCB5814E4459A057ED4D20F58A633152288A761214DCD28780B56',
2:h'\
AA67A169B0BBA217AA0AA88A65346920C84C42447C36BA5F7EA65F422C1FE5D8',
6:"sha-256"
},
{
1:"AP_BL31",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
2E6D31A5983A91251BFAE5AEFA1C0A19D8BA3CF601D0E8A706B4CFA9661A6B8A',
6:"sha-256"
},
{
1:"RMM",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
A1FB50E6C86FAE1679EF3351296FD6713411A08CF8DD1790A4FD05FAE8688164',
6:"sha-256"
},
{
1:"HW_CONFIG",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
1A252402972F6057FA53CC172B52B9FFCA698E18311FACD0F3B06ECAAEF79E17',
6:"sha-256"
},
{
1:"FW_CONFIG",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
9A92ADBC0CEE38EF658C71CE1B1BF8C65668F166BFB213644C895CCB1AD07A25',
6:"sha-256"
},
{
1:"TB_FW_CONFIG",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
238903180CC104EC2C5D8B3F20C5BC61B389EC0A967DF8CC208CDC7CD454174F',
6:"sha-256"
},
{
1:"SOC_FW_CONFIG",
5:h'\
5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
2:h'\
E6C21E8D260FE71882DEBDB339D2402A2CA7648529BC2303F48649BCE0380017',
6:"sha-256"
}
]
} >>,
h'\
31D04D52CCDE952C1E32CBA181885A40B8CC38E0528C1E89589807642AA5E3F2BC37\
F95374506BFF4D2E4BE7063C4D72419270C722E8D4D93EE8B6C9FACE3B43C9761A49\
941AB6F38FFDFF496AD463B4CBFA11D83E23E31F7F62329DE30C1CC8'
]) >>
],
44241: [
263,
<< 18([
h'A1013822',
{},
<< {
265:"tag:arm.com,2026:realm#2.0.0",
10:h'\
6E86D6D97CC713BC6DD43DBCE491A6B40311C027A8BF85A39DA63E9CE44C132A8A11\
9D296FAE6A6999E9BF3E4471B0CE01245D889424C31E89793B3B1D6B1504',
44236:"sha-256",
44240:"sha-256",
44235:h'\
54686520717569636B2062726F776E20666F78206A756D7073206F76657220313320\
6C617A7920646F67732E54686520717569636B2062726F776E20666F7820',
44237:h'\
A40102200221583076F988091BE585ED41801AECFAB858548C63057E16B0E676120B\
BD0D2F9C29E056C5D41A0130EB9C21517899DC23146B22583028E1B062BD3EA4B315\
FD219F1CBB528CB6E74CA49BE16773734F61A1CA61031B2BBF3D918F2F94FFC4228E\
50919544AE',
44238:h'\
311314AB73620350CF758834AE5C65D9E8C2DC7FEBE6E7D9654BBE864E300D49',
44239:[
h'\
24D5B0A296CC05CBD8068C5067C5BD473B770DDA6AE082FE3BA30ABE3F9A6AB1',
h'\
788FC090BFC6B8ED903152BA8414E73DAF5B8C7BB1E79AD502AB0699B659ED16',
h'\
DAC46A58415DC3A00D7A741852008E9CAE64F52D03B9F76D76F4B3644FEFC416',
h'\
32C6AFC627E55585C03155359F331A0E225F6840DB947DD96EFAB81BE2671939'
],
44243: 1, / MEC policy /
256: h'\
013333333333333333333333333333333333333333333333333333333333333333\
' / Instance ID /
} >>,
h'\
580B1DEA32D30AC6884C86B39CBE0FCB03BD00DF5103F9BAB01386A46A3BA8143E27\
ED6D4EB0D0A2724ABDF9640C09462FACE6DF186909DFA6EB131E3A7918276077ACDA\
B8A8BDECA6B0EAAFAB66E1439C1371F4FB1D6AAC047481B5DC75DD46'
]) >>
]
})
which has the following base16 encoding:
d9038ba219acca821901075905f4d28444a1013822a0590587aa19010978
237461673a61726d2e636f6d2c323032363a6363615f706c6174666f726d
23322e302e3019096858200d22e08a98469058486318283489bdb36f09db
efeb1864df433fa6e54ea2d71119095c58207f454c460201010000000000
0000000003003e0001000000505800000000000019010058210107060504
030201000f0e0d0c0b0a090817161514131211101f1e1d1c1b1a19181909
6144cfcfcfcf19095b193003190962677368612d32353619095a01190960
783a68747470733a2f2f7665726169736f6e2e6578616d706c652f2e7765
6c6c2d6b6e6f776e2f7665726169736f6e2f766572696669636174696f6e
19095f8da401695253455f424c315f320558205378796307535df3ec8d8b
15a2e2dc5641419c3d3060cfe32238c0fa973f7aa30258209a271f2a916b
0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa06677368
612d323536a401675253455f424c320558205378796307535df3ec8d8b15
a2e2dc5641419c3d3060cfe32238c0fa973f7aa302582053c234e5e8472b
6ac51c1ae1cab3fe06fad053beb8ebfd8977b010655bfdd3c30667736861
2d323536a401655253455f530558205378796307535df3ec8d8b15a2e2dc
5641419c3d3060cfe32238c0fa973f7aa30258201121cfccd5913f0a63fe
c40a6ffd44ea64f9dc135c66634ba001d10bcf4302a206677368612d3235
36a4016641505f424c310558205378796307535df3ec8d8b15a2e2dc5641
419c3d3060cfe32238c0fa973f7aa30258201571b5ec78bd68512bf7830b
b6a2a44b2047c7df57bce79eb8a1c0e5bea0a50106677368612d323536a4
016641505f424c320558205378796307535df3ec8d8b15a2e2dc5641419c
3d3060cfe32238c0fa973f7aa302582010159baf262b43a92d95db59dae1
f72c645127301661e0a3ce4e38b295a97c5806677368612d323536a40167
5343505f424c310558205378796307535df3ec8d8b15a2e2dc5641419c3d
3060cfe32238c0fa973f7aa302582010122e856b3fcd49f0636363174761
49cb730a1aa1cfaad818552b72f56d6f6806677368612d323536a4016753
43505f424c32055820f14b4987904bcb5814e4459a057ed4d20f58a63315
2288a761214dcd28780b56025820aa67a169b0bba217aa0aa88a65346920
c84c42447c36ba5f7ea65f422c1fe5d806677368612d323536a401674150
5f424c33310558205378796307535df3ec8d8b15a2e2dc5641419c3d3060
cfe32238c0fa973f7aa30258202e6d31a5983a91251bfae5aefa1c0a19d8
ba3cf601d0e8a706b4cfa9661a6b8a06677368612d323536a40163524d4d
0558205378796307535df3ec8d8b15a2e2dc5641419c3d3060cfe32238c0
fa973f7aa3025820a1fb50e6c86fae1679ef3351296fd6713411a08cf8dd
1790a4fd05fae868816406677368612d323536a4016948575f434f4e4649
470558205378796307535df3ec8d8b15a2e2dc5641419c3d3060cfe32238
c0fa973f7aa30258201a252402972f6057fa53cc172b52b9ffca698e1831
1facd0f3b06ecaaef79e1706677368612d323536a4016946575f434f4e46
49470558205378796307535df3ec8d8b15a2e2dc5641419c3d3060cfe322
38c0fa973f7aa30258209a92adbc0cee38ef658c71ce1b1bf8c65668f166
bfb213644c895ccb1ad07a2506677368612d323536a4016c54425f46575f
434f4e4649470558205378796307535df3ec8d8b15a2e2dc5641419c3d30
60cfe32238c0fa973f7aa3025820238903180cc104ec2c5d8b3f20c5bc61
b389ec0a967df8cc208cdc7cd454174f06677368612d323536a4016d534f
435f46575f434f4e4649470558205378796307535df3ec8d8b15a2e2dc56
41419c3d3060cfe32238c0fa973f7aa3025820e6c21e8d260fe71882debd
b339d2402a2ca7648529bc2303f48649bce038001706677368612d323536
586031d04d52ccde952c1e32cba181885a40b8cc38e0528c1e8958980764
2aa5e3f2bc37f95374506bff4d2e4be7063c4d72419270c722e8d4d93ee8
b6c9face3b43c9761a49941ab6f38ffdff496ad463b4cbfa11d83e23e31f
7f62329de30c1cc819acd182190107590278d28444a1013822a059020baa
190109781c7461673a61726d2e636f6d2c323032363a7265616c6d23322e
302e300a58406e86d6d97cc713bc6dd43dbce491a6b40311c027a8bf85a3
9da63e9ce44c132a8a119d296fae6a6999e9bf3e4471b0ce01245d889424
c31e89793b3b1d6b150419accc677368612d32353619acd0677368612d32
353619accb584054686520717569636b2062726f776e20666f78206a756d
7073206f766572203133206c617a7920646f67732e54686520717569636b
2062726f776e20666f782019accd586ba40102200221583076f988091be5
85ed41801aecfab858548c63057e16b0e676120bbd0d2f9c29e056c5d41a
0130eb9c21517899dc23146b22583028e1b062bd3ea4b315fd219f1cbb52
8cb6e74ca49be16773734f61a1ca61031b2bbf3d918f2f94ffc4228e5091
9544ae19acce5820311314ab73620350cf758834ae5c65d9e8c2dc7febe6
e7d9654bbe864e300d4919accf84582024d5b0a296cc05cbd8068c5067c5
bd473b770dda6ae082fe3ba30abe3f9a6ab15820788fc090bfc6b8ed9031
52ba8414e73daf5b8c7bb1e79ad502ab0699b659ed165820dac46a58415d
c3a00d7a741852008e9cae64f52d03b9f76d76f4b3644fefc416582032c6
afc627e55585c03155359f331a0e225f6840db947dd96efab81be2671939
19acd3011901005821013333333333333333333333333333333333333333
3333333333333333333333335860580b1dea32d30ac6884c86b39cbe0fcb
03bd00df5103f9bab01386a46a3ba8143e27ed6d4eb0d0a2724abdf9640c
09462face6df186909dfa6eb131e3a7918276077acdab8a8bdeca6b0eaaf
ab66e1439c1371f4fb1d6aac047481b5dc75dd46
A.2. Direct Mode
The following sample claim sets and the resulting CCA Token are
representative of a CCA Token using "direct mode" (Section 3.1).
In "direct mode" the eat_nonce claim in the Platform token contains a
hash of the Realm claims set, which includes verifier-provided
challenge data.
TODO
Acknowledgments
TODO
Contributors
Yogesh Deshpande
Arm Limited
Email: Yogesh.Deshpande@arm.com
Sergei Trofimov
Arm Limited
Email: Sergei.Trofimov@arm.com
Authors' Addresses
Simon Frost
Arm Limited
Email: Simon.Frost@arm.com
Thomas Fossati
Linaro
Email: thomas.fossati@linaro.org
Giri Mandyam
Advanced Micro Devices Inc
Email: gmandyam@amd.com