]> The Graduate University for Advanced Studies (SOKENDAI)

Japan n_aoki@ieee.org

SEC Supply Chain Integrity, Transparency, and Trust Working Group SCITT hardware IoT cloud compute attestation supply chain This document describes how SCITT can be applied to supply chains that include hardware components, IoT devices, firmware, cloud compute resources, confidential-computing environments, accelerators, and related operational evidence. It gives use cases and scope guidance. It also explains how SCITT can work with RATS, COSE, TCG technologies, SBOM, HBOM, CBOM, and cloud attestation systems without replacing those technologies. This document is informational. It does not define hardware assurance rules, cloud assurance rules, device identity systems, manufacturing requirements, or payload formats. Its purpose is to show where SCITT statements and receipts can provide transparency for heterogeneous supply-chain evidence, and where other standards or domain profiles should remain responsible. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the SCITT Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction SCITT provides building blocks for registering signed supply-chain statements in Transparency Services and for verifying those statements later. Although SCITT started from software supply-chain problems, real computing systems often contain software, firmware, hardware, identity, deployment, and runtime evidence together. An IoT device is not only a software package. It is a physical device with hardware components, firmware, bootloaders, operating system images, application containers, device identities, update policies, and operational state. A cloud compute resource is also not only a software image. It can include a VM image, hardware root of trust, confidential-computing environment, accelerator allocation, cloud-region policy, runtime attestation result, and operator authorization. SCITT can help by making statements about these objects transparent and verifiable. SCITT does not need to define the internal format of every evidence type. It can register statements from manufacturers, software suppliers, cloud providers, auditors, device operators, and verifiers. A relying party can later verify receipts and evaluate the evidence under its own policy. This document collects use cases and explains how to keep this work within a clear scope. It is intended to support future discussion of two possible building blocks:

• object binding and statement relationships; and
• composite verification over statement graphs.

Working Group Context Recent SCITT discussions show both interest and caution for hardware and graph use cases. The OCP case study showed that software and firmware provenance can be expressed with SCITT and that similar questions arise for hardware components, HBOM data, device identity, end-of-life state, and circular-economy evidence. The same discussion also made the scope question clear. Hardware supply-chain assurance can be outside the present charter if the WG tries to define hardware rules. However, hardware-related statements can still be carried as SCITT statements when another profile or venue defines their payload meaning and trust policy. The IETF 122 discussion is also relevant. It noted that several organizations can make statements about the same subject, and that SCITT can link things by subjects and statements even though this is not inherent in the basic common layer. It also raised the value of statements about statements and reliable locators. This document uses those points as design guidance. It does not ask SCITT to become a hardware standards body. It uses hardware, IoT, and cloud cases to show where a generic statement and graph layer may be useful.

Scope Position This document is careful about the SCITT scope. Hardware supply-chain details can be outside the current charter if the WG tries to standardize them as a hardware assurance system. At the same time, statements about hardware can be registered and verified as SCITT statements when the payload format and trust policy are defined elsewhere. Therefore, this document does not propose that SCITT define hardware assurance. It proposes that SCITT can provide transparency for signed statements about hardware, firmware, devices, and cloud resources, in the same way that SCITT can provide transparency for signed statements about software. The important boundary is this:

• SCITT can say that a statement was signed, registered, and linked to other statements.
• Domain profiles decide what the statement means and who is allowed to make it.
• A relying party decides whether the evidence is enough for its decision.

Non-Goals This document does not:

• define how to design secure IoT hardware;
• define manufacturing assurance requirements;
• define HBOM, CBOM, SBOM, VEX, attestation evidence, or cloud configuration schemas;
• define how a verifier decides whether an attested measurement is acceptable;
• define a universal hardware or cloud-resource registry;
• define a global device identity infrastructure;
• prevent authenticated issuers from making false claims;
• replace RATS, TCG, TPM, DICE, EAT, CoRIM, cloud-provider attestation, or existing BOM formats; or
• define procurement or compliance best practices.

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. This document uses the terms defined in SCITT and RATS .

Hardware Component:

A physical component such as a chip, sensor, board, secure element, module, accelerator, or peripheral.

Device Instance:

A specific physical device, such as an IoT gateway, sensor, controller, or embedded system.

Device Class:

A product model, configuration, or type shared by several Device Instances.

Cloud Compute Resource:

A cloud-provisioned resource such as a virtual machine, container worker, managed node, GPU allocation, accelerator resource, or serverless execution context.

Confidential-Computing Environment:

A trusted execution environment, confidential VM, enclave, or similar execution environment that can produce attestation evidence or results.

Lifecycle Evidence:

Statements that describe a protected object during design, manufacturing, provisioning, deployment, operation, update, audit, repair, transfer, retirement, or decommissioning.

Device Lifecycle Evidence Graph:

A statement graph that connects lifecycle evidence for a Device Instance or Device Class.

TODO: Align these terms with TCG, RATS, cloud-provider, OCP, and existing IETF terminology.

Relationship to Existing Work

SCITT SCITT provides the transparency and accountability layer for signed statements. In the use cases in this document, SCITT registers and verifies statements about hardware, firmware, device identity, cloud resources, and runtime evidence. SCITT does not need to understand each payload. A hardware statement can use an HBOM payload. A firmware statement can use an SBOM payload. A runtime statement can use a RATS Attestation Result. SCITT can provide registration and receipt verification around those payloads.

RATS RATS defines roles such as Attester, Verifier, and Relying Party. It defines a model for producing and evaluating evidence about a computing environment. SCITT can be used after or around that process. For example, a RATS Verifier can issue an Attestation Result and register it as a SCITT statement. A relying party can later verify that the result was signed and registered. SCITT should not define the meaning of the attested measurements. That remains with RATS profiles, platform profiles, and verifier policy.

TCG, TPM, DICE, and Hardware Roots of Trust Hardware roots of trust can provide device identity and measurements. These technologies can help create statements about device identity, boot state, firmware state, and platform configuration. SCITT can make those statements transparent. It does not replace the hardware root of trust or the protocol that produces evidence. TODO: Add exact references for TPM, DICE, CoRIM, and other relevant TCG work.

SBOM, HBOM, CBOM, and VEX BOM formats describe components, dependencies, vulnerabilities, or hardware composition. These formats are payloads from the SCITT point of view. SCITT can register statements carrying or referring to these payloads, but SCITT does not need to define the payload formats. TODO: Add references and examples for SPDX, CycloneDX, HBOM, CBOM, and VEX once the draft chooses the examples to include.

Use Case 1: Device-to-Cloud Firmware Provenance A device manufacturer produces a device with firmware and identity material. A component or platform vendor produces an SBOM for firmware. An audit report is recorded. A metadata service or signing service produces a signed certificate or statement. A final device or data center operator can verify receipts and check that the expected evidence exists. SCITT can help by registering statements for:

• device identity created during manufacturing;
• firmware SBOMs from component or platform vendors;
• firmware signing and release statements;
• audit reports;
• update authorization statements;
• attestation results from devices or verifiers; and
• receipts showing that these statements were registered.

This use case is close to firmware and software supply-chain transparency. It also shows why hardware identifiers and device identity may appear in SCITT statements.

Use Case 2: Extending Provenance from Firmware to Hardware Hardware supply-chain provenance can include hardware identifiers, component source, device identity, identity management, end-of-life state, repair state, and circular economy information. A hardware bill of materials can describe the hardware composition of a device, while firmware and software statements describe the software that runs on it. SCITT can register statements that refer to HBOM or hardware provenance data. It should not define the HBOM format itself. Example statements include:

• a manufacturer statement for a device class;
• a component supplier statement for a hardware component;
• a device identity statement for a device instance;
• an auditor statement about a manufacturing or assembly step;
• a repair statement;
• an end-of-life or transfer statement; and
• a statement that links a device instance to firmware and software evidence.

The value of SCITT here is not that it knows whether a hardware claim is true. The value is that the claim is signed, registered, and can be linked to other claims and receipts.

How SCITT Can Represent a Lifecycle Graph A lifecycle graph can be represented without changing the basic SCITT registration model. One possible pattern is:

1. Each evidence item is a SCITT Signed Statement.
2. Each statement is registered with a Transparency Service and receives a receipt.
3. A relationship statement or graph manifest links the statements.
4. The graph manifest can itself be registered as a SCITT Signed Statement.
5. A verifier checks statements, receipts, and graph edges under its policy.

This pattern lets different parties issue their own statements. A component supplier can issue a component statement. A manufacturer can issue a device identity statement. A software supplier can issue an SBOM statement. A RATS Verifier can issue an attestation result. An auditor can issue an audit statement. The graph can be discovered in different ways. A deployment can use locators in statements, a graph manifest, a subject-based index, or an auxiliary service. The SCITT Reference API does not need to become a full graph API for this use case. TODO: Decide which discovery pattern should be described as the main example and which should remain non-normative.

Use Case 3: Device Lifecycle Evidence Graph An IoT device can be described by evidence over time. A Device Lifecycle Evidence Graph can connect those statements. Hardware Component Statement ├─ provisionedWith -> Device Identity Statement ├─ runsFirmware -> Firmware SBOM or Firmware Signature Statement ├─ updatedBy -> Firmware/software Update Authorization Statement ├─ measuredBy -> RATS Attestation Result ├─ affectedBy -> Vulnerability Status Statement ├─ mitigatedBy -> Patch, Rollback, or Configuration Statement ├─ repairedBy -> Repair Statement └─ decommissionedBy -> End-of-Life Statement ]]> The graph does not need a single monolithic payload. Each statement can be issued by the party that is responsible for it. A composite verifier can later check whether the graph has the evidence required by a policy. This graph is not meant to be stored as one large payload. It can be built from separate statements and relationship statements. Earlier SCITT discussion raised the same idea through "statements about statements" and through reliable locators that can be used as pointers. The graph model in this document follows that direction.

Use Case 4: Cloud Compute Resource Integrity A cloud compute resource can involve several layers:

• cloud image or container image;
• host hardware platform;
• hypervisor or node software;
• confidential-computing environment;
• GPU or accelerator allocation;
• region or data residency constraint;
• tenant identity;
• deployment authorization; and
• runtime attestation result.

SCITT can register statements about these layers. For example, a cloud provider can issue a statement about a VM image and its host platform. A verifier can issue an attestation result. A tenant or deployment controller can issue an authorization statement for a workload. An auditor can issue an audit result. A composite verification profile can then check whether:

• the workload image matches the authorized digest;
• the runtime attestation result is recent;
• the confidential-computing environment is acceptable;
• the resource is in an allowed region;
• the accelerator firmware is covered by an accepted statement; and
• no statement revokes or conflicts with the evidence set.

Use Case 5: Device Repair, Transfer, and End of Life Devices can change hands, be repaired, or be retired. These events matter for supply-chain trust, especially for industrial IoT and enterprise hardware. These definitions are useful for meeting the industry's need for maintenance on a 10-year basis. SCITT can register statements for:

• repair events;
• replacement of a hardware component;
• re-provisioning of identity material;
• transfer of device ownership;
• end-of-support status;
• end-of-life status; and
• secure disposal or recycling status.

This document does not define the operational policy for these events. It only shows that they can be represented as lifecycle statements and linked into a graph.

Scope Questions Question: Does this document ask SCITT to publish hardware assurance rules? Answer: No. It describes how SCITT statements and receipts can be used for hardware-related evidence. Hardware assurance rules, HBOM formats, and device identity policy should be defined elsewhere. Question: If hardware supply chain is out of scope, why discuss hardware at all? Answer: Because SCITT statements can carry or refer to hardware-related payloads. The useful SCITT question is not "how should hardware be built?" The useful SCITT question is "how can a signed hardware-related statement be registered, linked, and verified with other statements?" Question: Should graph relationships be put in the payload or header? Answer: This document does not decide that. It lists possible placements: payloads, protected metadata if later defined, graph manifest statements, or auxiliary services. A profile must say which placement is authoritative. Question: Does a device lifecycle graph prove that the device is safe? Answer: No. It helps a relying party see which statements exist and how they relate. The relying party still applies its own policy.

Common Evidence Types The following evidence types appear across the use cases:

• manufacturing statement;
• component provenance statement;
• device identity statement;
• firmware SBOM statement;
• hardware BOM statement;
• cloud image statement;
• deployment authorization statement;
• update authorization statement;
• RATS Attestation Result statement;
• vulnerability status statement;
• audit result statement;
• repair statement;
• transfer statement; and
• decommissioning statement.

TODO: Decide which evidence types should be examples only and which should be registered in a future object-binding or relationship vocabulary document.

Scope Boundary Examples The following table gives examples of what belongs in SCITT and what should stay outside SCITT.

Topic	SCITT role	Other responsible work
Firmware SBOM	register and receipt a signed statement	SBOM format and tooling
HBOM	register and receipt a signed statement	HBOM format and hardware domain
TPM quote	carry or refer to an attestation result	TCG, RATS, platform profile
Cloud region claim	register and link the signed claim	cloud provider and policy profile
Device identity	register statements and link evidence	manufacturer, TCG, device profile
False hardware claim	preserve signed evidence and audit trail	issuer governance and legal process
Composite decision	provide evidence and result structure	relying-party policy

Possible Future Work This document motivates two possible follow-on drafts. First, a Protected Object Binding draft can define how a statement refers to a software, firmware, hardware, device, or cloud object. It can also define a small relationship vocabulary. Second, a Composite Evidence Verification draft can define how a verifier asks for a graph-level decision and how the verifier reports missing, stale, or conflicting evidence. Both follow-on drafts should keep payload definitions out of scope unless a separate charter or venue says otherwise.

Privacy Considerations Hardware and cloud evidence can reveal sensitive information. Device identifiers can identify customers. Graph edges can reveal suppliers, cloud regions, tenants, repair history, or operational dependencies. Deployments should avoid placing directly identifying information in public logs. They can use pseudonymous identifiers, salted commitments, encrypted payloads, access control, or selective disclosure. The chosen method should still allow the intended verifier to check the required evidence.

Security Considerations The main risk is over-reading SCITT evidence. A valid receipt does not prove that a hardware claim is true. It proves that a signed statement was registered and that the receipt verifies under the relevant profile. Relying parties must still decide:

• which issuers are trusted for each statement type;
• which statements are required;
• how fresh each statement must be;
• how conflicts are handled;
• how revocation or supersession is handled; and
• whether a domain-specific payload is acceptable.

Other risks include:

• linking the wrong device instance to a statement;
• treating a device class statement as a device instance statement;
• accepting old attestation results;
• accepting a hardware statement from an unauthorized issuer;
• exposing sensitive graph data; and
• assuming that SCITT replaces RATS or hardware root-of-trust mechanisms.

IANA Considerations This document has no IANA actions.

References Normative References 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. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Informative References 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. While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). However, this data can be moderately sensitive in many applications. While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations. This document updates RFC 3711, the SRTP specification, and defines Cryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of facilitating deployment. CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. 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. n.d. n.d. n.d. n.d. n.d. n.d. n.d.

Open Questions

• Should SCITT define generic object binding, or should each domain profile define its own binding?
• Should relationship metadata live in payloads, protected headers, graph manifests, or auxiliary services?
• Should SCRAPI remain focused on registration and receipt retrieval while graph discovery is handled by later auxiliary services?
• Which use cases require WG action, and which should be handled by other WGs or standards bodies?
• How should this document describe hardware use cases if the current charter does not allow the WG to publish a hardware-specific standards-track item?

Design Notes for Future Revisions This revision treats hardware and cloud compute as use cases for SCITT statements, not as a request for SCITT to define hardware or cloud assurance. That distinction is important for charter discussion. This revision also adds the IETF 122 points on multi-party statements, statements about statements, reliable locators, and the limits of the basic common layer. These points support the Device Lifecycle Evidence Graph without requiring SCRAPI to become a graph API.

Acknowledgments The author thanks the SCITT WG participants for discussion of OCP hardware assertions, generic APIs, graph building over opaque payloads, and the boundary between SCITT and domain-specific hardware or cloud profiles. The OCP case study helped identify the need to discuss hardware identifiers, device identity, HBOM provenance, end-of-life information, and circular-economy evidence without turning SCITT into a hardware assurance framework.