]> Arm Limited

Simon.Frost@arm.com

Linaro

thomas.fossati@linaro.org

Mediatek Inc

giridhar.mandyam@gmail.com

Internet-Draft 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.

Introduction The Arm Confidential Compute Architecture (CCA) is a set of hardware and firmware specifications, backed by a reference implementation . 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 , 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 and, as a design decision, the CCA attestation token is a profile of the Entity Attestation Token (EAT) . Note that there are other profiles of EAT available, such as and , 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 1.0 . As mentioned in the abstract, this memo documents a vendor extension to the RATS architecture, and is not a standard.

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 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 . 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 .

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) .

CCA Attester Model There are two kinds of CCA Attester: direct and delegated. Their architectural arrangements are described in and , respectively. Both arrangements implement a "layered attester" () 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.

CCA Attester

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 collection. The intra-collection binding is detailed in . change addresses: Issue #16

Delegated The structure of the CCA delegated Attester is illustrated in . 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 collection. The intra-collection binding is detailed in . TODO: Device Token

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 .

CCA Attester Boot Phase | | '--------|-------------|-------------|----' | | | ]]>

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 ). How the CPAK is derived is implementation-specific.

CCA Attester Run-time Phase | Plat Token | | +-------------->| | | | | | Realm | | | State | | | | | | | | | | | v | | | Realm | | | Token | | | | | | sign .---+ | | w/ | | | | RAK '-->| | | | | | | | | | CCA Token | | +---------->| | | | ]]>

A reference implementation of the CCA Attester is provided by .

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 for more details. The above tokens are presented to the requester within a top level Conceptual Message Wrapper (CMW) collection . CDDL along with text descriptions is used to define each claim independent of encoding. The following CDDL type(s) are reused by different claims:

CCA Attestation Token top level wrapper The above tokens are presented to the requester within a top level CMW collection . The collection map has two 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 model is used by an implementation. [ eat-cwt-coap-cf bytes .cbor COSE_Sign1 ] 0xACD1 => [ eat-cwt-coap-cf bytes .cbor COSE_Sign1 ] } ]]>

CCA Platform token Claims

Caller Claims

CCA Platform Nonce The Nonce claim is used to carry a challenge provided by the caller to demonstrate freshness of the generated token. The 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.

Where the CCA Platform implementation uses the Delegated Token signing model , the value of the Nonce claim will be a hash of the Realm Public Key claim of the CCA Realm State token . This claim MUST be present in a CCA Platform attestation token. arm-platform-hash-type ) ]]>

Target Identification Claims

CCA Platform Instance ID The Instance ID claim represents the unique identifier of the Platform 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 of the PAK.

This claim MUST be present in a CCA Platform attestation token. arm-platform-instance-id-type ) ]]>

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. Note that this identifies the CCA Platform implementation, not a particular instance. To uniquely identify an instance, see the Instance ID claim . arm-platform-implementation-id-type ) ]]>

Target State Claims

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. See , for considerations about backwards compatibility with previous versions of the CCA Platform attestation token format. arm-platform-profile-type ) ]]>

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 . 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.

CCA Platform Lifecycle States + Terminate +<----------' '---------------' | | v .----------------. | Decommissioned | '----------------' ]]>

The CDDL representation is shown below. provides the mappings between and the data model. arm-platform-lifecycle-type ) ]]> arm-platform-lifecycle-unknown-type is not shown in ; it represents an invalid state that must not occur in a system. Lifecycle States Mappings

CDDL	Lifecycle States
arm-platform-lifecycle-unknown-type
arm-platform-lifecycle-assembly-and-test-type	Assembly and Test
arm-platform-lifecycle-platform-rot-provisioning-type	CCA Platform Provisioning
arm-platform-lifecycle-secured-type	Secured
arm-platform-lifecycle-non-platform-rot-debug-type	Non-Recoverable CCA Platform Debug
arm-platform-lifecycle-recoverable-platform-rot-debug-type	Recoverable CCA Platform Debug
arm-platform-lifecycle-decommissioned-type	Decommissioned

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. arm-platform-config-type ) ]]>

Platform 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 arm-platform-manufacturing-config-type ) ]]>

Software Inventory Claims

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. 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 , 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. 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 } arm-platform-sw-components = ( arm-platform-sw-components-label => [ + arm-platform-sw-component ] ) ]]>

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.

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.

Version 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.

Signer ID 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.

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" .

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" . The CCA platform hash algorithm ID claim MUST be present in a CCA platform token. text ) ]]>

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. arm-platform-client-id-type ) ]]>

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 arm-platform-manufacturing-config-type ) ]]>

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 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 ] ) ]]>

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. arm-platform-peer-signers-type ) ]]>

CCA Platform TBB ROTPK Where an implementation of the CCA platform follows the Trusted Board Boot specification , 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 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 ) ]]>

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.

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 URL specifying the address of the verification service API). A Relying Party may choose to ignore this claim in favor of other information. 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.

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.

Realm Nonce The Nonce claim is used to carry a challenge provided by the caller to demonstrate freshness of the generated token. The 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. cca-realm-challenge-type ) ]]>

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_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: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-type ) ]]>

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. cca-realm-personalization-value-type ) ]]>

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. cca-realm-measurement-type ) ]]>

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. [ 4*4 cca-realm-measurement-type ] ) ]]>

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" . This claim MUST be present in a CCA Realm state attestation token. text ) ]]>

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. cca-realm-public-key-type ) ]]>

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 such that it can be presented as a Challenge for the bound CCA Platform token . This claim MUST be present in a CCA Realm state attestation token. text ) ]]>

Backwards Compatibility Considerations This profile conforms to the claims in the Beta release of the 2.0 release of the Realm Management Monitor specification. . TODO Backwards compat incl notes 1.1./2.0 with note that 1.0 is theoretical

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 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 and Realm Public Key Hash Algorithm ID claims will not be used.

Reference Profile

Token Encoding and Signing The CCA attestation token is encoded in CBOR format. The CBOR representation of a CCA attestation token MUST be "valid" according to the definition in . Besides, only definite-length string, arrays, and maps are allowed. The CCA reference profile is designed to not emit CBOR preferred serializations (). This profile assumes that the Verifier MUST be a variation-tolerant CBOR decoder. Cryptographic protection is obtained by wrapping the CCA Platform and Realm state claims-set each in a COSE Web Token (CWT) . The signature structure MUST be a tagged (18) COSE_Sign1 . 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 . 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 ().

Freshness Model The CCA token supports the freshness models for attestation Evidence based on nonces and epoch handles (Section and Section of ) 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.

Synopsis presents a concise view of the requirements described in the preceding sections. Baseline Profile

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 Serialization	Variant serialization MAY be used
COSE Protection	COSE_Sign1 MUST be used
Algorithms	SHOULD be used
Detached EAT Bundle Usage	Detached EAT bundles MUST NOT be sent
Verification Key Identification	Any identification method listed in
Endorsements	See
Freshness	nonce or epoch ID based
Claims	Those defined in . As per general EAT rules, the receiver MUST NOT error out on claims it does not understand.

Collated CDDL [ eat-cwt-coap-cf, bytes .cbor COSE_Sign1, ], 0xACD1 => [ eat-cwt-coap-cf, bytes .cbor COSE_Sign1, ], } COSE_Sign1 = #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-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-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,2024: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 = (cca-realm-mec-policy-label => "shared" / "\ private") label = int / tstr values = any COSE_Key = { 1 => tstr / int, ? 2 => bstr, ? 3 => tstr / int, ? 4 => [+ tstr / int], ? 5 => bstr, * label => values, } arm-platform-claims = arm-platform-claim-map arm-platform-claim-map = { arm-platform-profile, arm-platform-challenge, 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-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-hash-type = bytes .size 32 / bytes .size 48 / bytes .\ size 64 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,2024:cca_platform#2.0.0" 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, } 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) 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' 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), ) ]]>

Signing key implementation alternatives In the CCA Platform reference design, PAKs () 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 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 . 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 token

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 endorsed 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 }. 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 lll 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 .

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.

AR4SI Trustworthiness Claims Mappings 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 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 TODO: LFA FAL AR4SI Claims mappings

Trustworthiness Vector claims	Related PSA claims
configuration	Software Components ()
executables	ditto
file-system	N/A
hardware	Implementation ID () and CCA Platform config (TODO)
instance-identity	Instance ID (). The Security Lifecycle () can also impact the derived identity.
runtime-opaque	Indirectly derived from executables, hardware, and instance-identity. The Security Lifecycle () 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.

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 .

Endorsements, Reference Values and Verification Key Material The defines a protocol based on the data model that can be used to convey CCA Endorsements, Reference Values and Verification Key Material to the Verifier.

Implementation Status RFC Editor: please remove this section before publication. Implementations of this specification are provided by the Trusted Firmware-RMM project and the Veraison project . These implementations are released as open-source software.

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.

IANA Considerations TODO: Issue #34 find document centric change controller TODO: additional top level claims

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 .

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): unsigned integer
• Change Controller: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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): byte string
• Change Controller: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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: TBD
• Specification Document(s): of RFCthis

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 with the eat_profile parameter set to tag:arm.com,2023:cca_platform#1.0.0.

CoAP Content-Formats Registration IANA is requested to register a CoAP Content-Format ID in the "CoAP Content-Formats" registry :

• 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).

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

References Normative References Arm Arm Arm Arm Arm The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. IANA Security Theory LLC Mediatek USA Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. Security Theory LLC Fraunhofer Institute for Secure Information Technology Linaro Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EAT). Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. IANA CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. Informative References Microsoft Microsoft Intel Intel Intel Intel® Trust Domain Extensions (TDX) introduce architectural elements designed for the deployment of hardware-isolated virtual machines (VMs) known as trust domains (TDs). TDX is designed to provide a secure and isolated environment for running sensitive workloads or applications. This Entity Attestation Token (EAT) profile outlines claims for an Intel TDX attestation result which facilitate the establishment of trust between a relying party and the environment. Qualcomm Technologies Inc. Qualcomm Technologies Inc. Qualcomm Technologies Inc. An attestation format based on the Entity Attestation Token (EAT) is described. The Qualcomm Wireless Edge Services (QWES) token is used in the context of device onboarding and authentication. It is verified in the same manner as any CBOR Web Token (CWT). The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. IANA Trusted Firmware Project The Veraison Project Fraunhofer SIT Linaro arm Independent Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. Cisco Systems Fraunhofer SIT MIT Linaro Intel This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. Arm Ltd Linaro Arm Confidential Computing Architecture (CCA) Endorsements comprise reference values and cryptographic key material that a Verifier needs to appraise Attestation Evidence produced by an Arm CCA system. This memo defines CCA Endorsements as a profile of the CoRIM data model. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/yogeshbdeshpande/draft-cca-rats-endorsements.

Examples 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 () of SECURED.

Delegated Mode The following sample claim set and token are representative of a CCA Token using "delegated mode" described in . In this model, the eat_nonce claim in the Platform token contains a hash of the RAK public key claim in the Realm token.

Platform Claims Set The CCA Platform claims set is

Realm Claims Set The CCA Realm claims set is >, 44238: h'\ 311314AB73620350CF758834AE5C65D9E8C2DC7FEBE6E7D9654BBE864E300D49', \ / RIM / 44239: [ h'\ 24D5B0A296CC05CBD8068C5067C5BD473B770DDA6AE082FE3BA30ABE3F9A6AB1', \ / REM[0] / h'\ 788FC090BFC6B8ED903152BA8414E73DAF5B8C7BB1E79AD502AB0699B659ED16', \ / REM[1] / h'\ DAC46A58415DC3A00D7A741852008E9CAE64F52D03B9F76D76F4B3644FEFC416', \ / REM[2] / h'\ 32C6AFC627E55585C03155359F331A0E225F6840DB947DD96EFAB81BE2671939' \ / REM[3] / ], 44243: "private" / MEC policy / } ]]>

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

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

Signed and Bound Assembly The resulting CMW collection is >, h'\ 31D04D52CCDE952C1E32CBA181885A40B8CC38E0528C1E89589807642AA5E3F2BC37\ F95374506BFF4D2E4BE7063C4D72419270C722E8D4D93EE8B6C9FACE3B43C9761A49\ 941AB6F38FFDFF496AD463B4CBFA11D83E23E31F7F62329DE30C1CC8' ]) >> ], 44241: [ 263, << 18([ h'A1013822', {}, << { 265:"tag:arm.com,2024: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: "private" / MEC policy / } >>, h'\ 580B1DEA32D30AC6884C86B39CBE0FCB03BD00DF5103F9BAB01386A46A3BA8143E27\ ED6D4EB0D0A2724ABDF9640C09462FACE6DF186909DFA6EB131E3A7918276077ACDA\ B8A8BDECA6B0EAAFAB66E1439C1371F4FB1D6AAC047481B5DC75DD46' ]) >> ] }) ]]> which has the following base16 encoding:

Direct Mode The following sample claim sets and the resulting CCA Token are representative of a CCA Token using "direct mode" (). 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 Arm Limited

Yogesh.Deshpande@arm.com

Arm Limited

Sergei.Trofimov@arm.com