]> The Graduate University for Advanced Studies (SOKENDAI)

Japan n_aoki@ieee.org

SEC Supply Chain Integrity, Transparency, and Trust Working Group SCITT supply chain protected object statement graph transparency This document defines a small common model for relating Supply Chain Integrity, Transparency, and Trust (SCITT) Signed Statements to the supply-chain objects that those statements describe, measure, authorize, revoke, or audit. The model can be used for software artifacts, firmware artifacts, hardware components, device instances, cloud compute resources, and other objects that appear in supply-chain evidence. The document also defines a relationship vocabulary and an optional Statement Graph Manifest. These parts help verifiers connect heterogeneous SCITT statements without requiring SCITT to define the payload formats of those statements. This document does not define SBOM, HBOM, CBOM, attestation, audit, vulnerability, or regulatory payload formats. It only defines a common binding and graph layer around SCITT statements and receipts. 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 defines an architecture for trustworthy and transparent supply-chain statements. A producer signs a statement, a Transparency Service registers it, and a consumer can later verify the signed statement and its receipt. Many supply-chain decisions need more than one statement. A device can be covered by a device identity statement, a hardware statement, a firmware SBOM, an update authorization statement, an attestation result, a vulnerability statement, and an audit statement. Each statement can be valid by itself, but a consumer often needs to know whether these statements refer to the same object and how they relate to each other. SCITT intentionally keeps payloads opaque to the common layer. This is useful because different ecosystems use different payload formats. It also creates a small gap: a generic verifier can verify that a statement was registered, but it may not know what object the statement is about unless it understands the payload. That makes graph discovery, evidence packaging, and cross-domain tools harder. This document fills that gap with a narrow binding model. It does not turn SCITT into a hardware or cloud assurance framework. It also does not ask the Transparency Service to understand every payload. Instead, it defines a small set of optional common fields that can be carried by a profile, a payload, or a future envelope extension. These fields say which object a statement is about and how that statement relates to other statements. The model is intended to support the following tasks:

• linking a statement to a software, firmware, hardware, device, or cloud object;
• referring to a SCITT statement and its receipt in a stable way;
• expressing common relationships such as describes, measures, authorizes, supersedes, and revokes;
• building a small graph of evidence for later verification; and
• keeping domain-specific semantics in domain profiles.

TODO: Align this document with the latest SCITT Architecture terminology before submission. In particular, confirm whether the term "Protected Object" should be replaced with "Supply-Chain Object", "Artifact Subject", or another term.

Working Group Context The design of this draft follows two points that have come up in SCITT discussions. First, SCITT is already able to carry statements from more than one party about the same subject. One party can publish a statement about an artifact, and another party can later publish a counter-statement, a fix statement, or an audit statement. This draft makes that pattern easier to use by giving tools a small way to name the subject and to describe the relationship between statements. Second, SCITT is content-agnostic by design. This is important. It lets SCITT work with many payload formats. The same design also means that a generic tool cannot always find the subject, the graph, or the latest related statement without help. This draft provides that help as optional metadata and graph statements. The signed statement is still the SCITT unit of registration. The IETF 122 discussion noted that SCITT can link things together through subjects and statements, but that this is not inherent in the basic model. It also noted that reliable locators in SCRAPI can be used as pointers, and that "statements about statements" may help describe messy build or update flows. The IETF 124 discussion raised the same design question for software, hardware, and other artifacts: where should graph information live, and how much should the common SCITT layer expose? This draft takes a conservative position. It does not change the basic Transparency Service function. A Transparency Service can still register signed statements and return receipts. Graph support can be provided by profiles, graph manifest statements, protected metadata if defined by a future profile, or auxiliary services.

Why This Is Still About Statements A likely question is why SCITT needs an object binding model when SCITT already works with statements. The answer is that this document does not make objects a new primary SCITT resource. The signed statement remains the unit registered in SCITT. The object binding is only a common way to say what that statement is about. This distinction matters for scope:

• A Transparency Service can continue to register opaque signed statements.
• A domain profile can decide whether the binding is placed in the payload, in a protected header, or in a separate graph manifest.
• A verifier can use the binding only when it needs cross-statement analysis.
• The truth of the payload remains a domain and issuer matter.

The binding is therefore an aid for statement discovery and statement graph construction. It is not a new guarantee that the object is safe, compliant, or correct.

Scope Questions and Answers This section records expected scope questions. Question: SCITT handles statements. Why define Protected Objects? Answer: Protected Objects are not a new SCITT registry resource. They are a small way to identify what a statement is about. The registered item remains a Signed Statement. The binding only helps a verifier connect several statements that refer to the same object. Question: Does this draft make SCITT a hardware supply-chain standard? Answer: No. Hardware-specific assurance, HBOM formats, hardware roots of trust, and manufacturer policy remain outside this draft. This draft only says how a signed statement about such material can be linked to other SCITT statements and receipts. Question: Does this draft require SCRAPI to become a graph API? Answer: No. SCRAPI can remain a registration and receipt API. Graph discovery can be done by a later auxiliary service or by exchanging a Statement Graph Manifest. Question: Does a valid graph prove that all claims are true? Answer: No. A valid graph proves that the statements, receipts, and relationships satisfy a chosen verification policy. It does not prove that an issuer told the truth.

Scope This document is in scope when it defines common building blocks for relating SCITT Signed Statements and receipts. These building blocks are useful across software, firmware, hardware, IoT, cloud, and other supply-chain domains. This document defines:

• a Protected Object Binding information model;
• Statement Reference and Receipt Reference information models;
• a small relationship vocabulary;
• an optional Statement Graph Manifest; and
• common verification and security considerations.

Non-Goals This document does not:

• define the payload format for SBOM, HBOM, CBOM, VEX, attestation evidence, audit reports, regulatory reports, or operational logs;
• define whether a manufacturer, cloud provider, device operator, auditor, or regulator made a true claim;
• define a global registry for devices, hardware, cloud resources, or supply chain objects;
• define best practices for designing a software, hardware, IoT, or cloud supply chain;
• require a Transparency Service to index or query graphs;
• require a particular identifier scheme for devices, hardware, or cloud resources;
• define an authorization policy language; or
• define domain-specific compliance rules.

TODO: Decide whether this document should stay Standards Track or begin as Informational until the WG agrees on the boundary between generic SCITT metadata and domain-specific payloads.

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 CBOR diagnostic notation where helpful. JSON examples are illustrative unless a profile states otherwise.

Protected Object:

A physical or non-physical supply-chain object about which one or more SCITT Signed Statements are made. Examples include a software package, firmware image, source repository, container image, hardware component, device instance, virtual machine, confidential-computing enclave, GPU allocation, cloud service, or integrated product.

Object Binding:

A data structure that relates a SCITT Signed Statement to a Protected Object.

Statement Reference:

A stable reference to a SCITT Signed Statement, a statement digest, a Transparency Service registration identifier, or another identifier that lets a verifier retrieve or identify the statement.

Receipt Reference:

A stable reference to a SCITT receipt or receipt bundle that lets a verifier verify registration of a statement in a Transparency Service.

Relationship Edge:

A directed edge that states how two nodes are related. A node can be a Protected Object, a Statement Reference, or a Receipt Reference.

Statement Graph:

A set of nodes and Relationship Edges.

Statement Graph Manifest:

A signed statement that commits to a Statement Graph or to a useful subset of a Statement Graph.

Subject:

The main node to which a graph, manifest, or verification request applies.

Protected Object Binding Model A Protected Object Binding identifies the object that a statement describes, measures, authorizes, revokes, audits, or otherwise relates to. The binding is meant to be small. A profile can add fields, but it SHOULD keep the common binding stable enough for generic tools to compare objects and build graphs. any} } digest = { alg: tstr, value: bytes } lifecycle-phase = "design" / "build" / "manufacture" / "provision" / "deploy" / "operate" / "update" / "audit" / "repair" / "transfer" / "retire" / "decommission" / tstr ]]> The object_type field identifies the kind of object. Initial values are listed in . The object_id field identifies the object within a namespace chosen by an issuer, a domain profile, or another recognized authority. This document does not create a single global identifier system. The object_digest field binds the object to bytes, measurements, a canonical descriptor, or another profile-defined representation. Some hardware and cloud resources do not have one stable byte string. In such cases, a profile can use a measurement digest, configuration digest, or other fingerprint. The object_locator field gives one or more locations where an object or object descriptor can be found. A locator MUST NOT be treated as stable identity unless a profile says so. The object_instance_id field distinguishes an object class from a specific object instance. For example, a firmware digest can identify an artifact, while a serial number or attested device identity can identify a device instance. The lifecycle_phase field gives coarse lifecycle context. It is not a full lifecycle model. A domain profile can define more precise values. The issuer_scope field can be used when an object_id is only meaningful in the issuer's namespace.

Statement Reference A Statement Reference identifies a SCITT statement that is part of a graph. any} } ]]> A Statement Reference MUST contain enough information for the intended verifier to identify the statement. A profile MAY require a digest, URI, registration identifier, or a combination of these values. A verifier MUST NOT trust a URI by itself. When a digest is present, the retrieved statement MUST match the digest. When a receipt is present, the verifier MUST verify the receipt under the applicable receipt profile.

Receipt Reference A Receipt Reference identifies a receipt for a statement. any} } ]]> A Receipt Reference MAY identify a detached receipt, an embedded receipt, or a bundle of receipts. A verifier MUST apply the receipt profile named or implied by the receipt.

Relationship Edge A Relationship Edge connects two graph nodes. The edge states a relation name, the source node, and the target node. any} } node-id = tstr relation-name = tstr ]]> The asserted_by field can identify the statement that asserts the edge. A profile SHOULD use this field when edge authority matters. A verifier MUST apply a policy that states which issuers are allowed to assert which relations. A valid signature alone does not give authority to assert any relation.

Initial Relationship Vocabulary This document defines the following initial relation names. Relation names are case-sensitive ASCII strings. A profile MAY define extra names using a URI or a registered extension value.

describes:

The source statement describes the target object or statement.

identifies:

The source statement provides identity information for the target object.

partOf:

The source object is a part of the target object.

contains:

The source object contains the target object.

builtFrom:

The source object was built from the target object.

derivedFrom:

The source object or statement is derived from the target object or statement.

runsOn:

The source software, firmware, or workload runs on the target platform or compute resource.

measures:

The source statement reports a measurement of the target object.

attests:

The source statement attests to a property of the target object.

authorizes:

The source statement authorizes an action concerning the target object.

observes:

The source statement records an observed state or event concerning the target object.

supersedes:

The source statement replaces the target statement for a purpose defined by policy.

revokes:

The source statement says that the target statement should not be accepted for a purpose defined by policy.

conflictsWith:

The source statement cannot be accepted with the target statement under the same policy unless that policy resolves the conflict.

aggregates:

The source statement groups the target statements or objects.

dependsOn:

The source statement or object depends on the target statement or object.

audits:

The source statement is an audit result for the target statement or object.

TODO: Decide whether this vocabulary should be an IANA registry, a closed list, or a profile-specific registry with expert review.

Initial Object Types This document defines the following initial object type strings:

• source-repository
• software-package
• container-image
• firmware-image
• hardware-component
• hardware-platform
• device-class
• device-instance
• cloud-image
• cloud-compute-resource
• confidential-computing-environment
• accelerator-resource
• service-endpoint
• integrated-product

TODO: Decide whether terms such as TPM, TEE, GPU, and IoT gateway should be registered object types or examples under broader object types.

Statements about Statements A Statement Graph can include a statement that is about another statement. This pattern is useful when a later event changes how a previous statement should be used. Examples include:

• a vulnerability statement that refers to a previous SBOM statement;
• a fix statement that says a reported issue has been corrected;
• a revocation statement for a previous release statement;
• an audit statement about a submitted statement;
• a supersession statement that says a new statement is the current one for a given purpose; and
• a graph manifest statement that commits to a set of statement references and relationship edges.

This draft does not define the payload format of these statements. It only defines references and relation names that allow a verifier to build a graph. A profile MUST say which issuers are allowed to assert a relationship about another statement. For example, an arbitrary third party should not be able to revoke a manufacturer statement unless the verification policy grants that authority.

Statement Graph Manifest A Statement Graph Manifest packages a set of nodes and edges. It can be used for offline verification, for evidence exchange, or to commit to a graph digest. The manifest MAY itself be a SCITT Signed Statement. any} } graph-node = { id: node-id, node: protected-object-binding / statement-reference, ? receipt: receipt-reference, ? attributes: {* tstr => any} } ]]> The following example is illustrative. TODO: Define a canonical graph digest algorithm. The algorithm needs to handle node ordering, edge ordering, duplicate edges, and differences between JSON and CBOR encodings. The IETF 124 discussion noted that deterministic encoding is an open issue for graph work; this draft should not claim that problem is solved until the WG agrees on an approach.

Graph Digest Requirements A graph digest is useful when a graph is exchanged between tools or registered as a statement. A graph digest can also help a verifier detect that a graph was changed after it was prepared. A future version of this document needs a deterministic graph digest algorithm. The algorithm should define at least the following:

• the canonical form of each node;
• the canonical form of each edge;
• how node identifiers are sorted;
• how edges are sorted;
• how duplicate edges are handled;
• how missing optional fields are handled;
• how JSON and CBOR encodings are compared, if both are allowed; and
• how profiles add fields without breaking the digest.

Until that algorithm is defined, implementations SHOULD NOT compare graph digests across independent implementations unless they use the same private profile. TODO: Define or reference a deterministic encoding and graph digest method after WG review.

Placement of Binding Data A binding can appear in more than one place. This document does not require one placement. A profile MAY place binding data:

• inside the payload of a domain-specific SCITT statement;
• in a generic graph manifest statement;
• in a protected header if a future SCITT or COSE profile defines such use; or
• in an auxiliary service response that is verified against registered statements and receipts.

A profile MUST state which placement it uses. A verifier MUST know which placement is authoritative for the profile it is applying. TODO: Coordinate this section with any SCITT list discussion on whether some metadata about opaque payloads belongs in a COSE protected header.

Verification Procedure A verifier that processes a Statement Graph Manifest SHOULD perform the following steps:

1. Parse the manifest and validate its syntax.
2. Resolve each Statement Reference required by the applicable policy.
3. Verify each Signed Statement according to COSE and SCITT requirements.
4. Verify each receipt according to the applicable receipt profile.
5. Validate that each required statement is bound to the expected Protected Object.
6. Construct the graph from nodes and edges.
7. Check that each required edge is present.
8. Check that each edge was asserted by an issuer allowed by policy.
9. Report missing statements, invalid receipts, stale statements, unresolved references, and conflicts.

A verifier MUST NOT treat successful graph verification as proof that all claims inside the statement payloads are true. Successful graph verification only means that the statements, receipts, and edges satisfy the selected policy.

Privacy Considerations Object identifiers and graph edges can reveal sensitive information about customers, devices, cloud tenants, locations, supply-chain partners, and operational dependencies. Profiles using this document SHOULD minimize public identifiers when public Transparency Services are used. They MAY use pseudonymous identifiers, salted commitments, encrypted payloads, access-controlled graph manifests, or selective disclosure. A privacy mechanism MUST still allow the intended verifier to confirm the object binding and relationship semantics required by policy.

Security Considerations This document introduces graph-level relationships that can affect verifier decisions. A wrong or malicious edge can make an evidence set look complete when it is not. Implementations MUST verify signatures and receipts before using any edge. Implementations MUST also apply an authorization policy for relation assertions. The following risks need attention:

• Confused identity: two different objects are treated as the same object.
• Graph injection: a presenter adds irrelevant but valid statements to a graph.
• Omitted conflict: a presenter omits a conflicting statement.
• Unauthorized revocation: an issuer revokes or supersedes a statement without authority.
• Stale graph: a verifier accepts old evidence as if it were current.
• Privacy leakage: a graph reveals sensitive operational relationships.
• Ambiguous encoding: two implementations compute different graph digests for the same intended graph.

TODO: Add a formal threat model aligned with the SCITT Architecture threat model and with RATS terminology where attestation results are used.

IANA Considerations This document requests no IANA action yet. TODO: The WG should decide whether to create registries for:

• SCITT protected object type names;
• SCITT relation names;
• SCITT graph manifest media types; and
• graph verification result codes.

If registries are created, this document should define registration policies and initial contents.

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

Design Notes for Future Revisions This revision reflects four working assumptions. First, the generic layer should not need to parse every domain payload. A small binding layer can help tools build graphs even when payloads remain opaque. Second, graph support should not delay the core SCITT Reference API. A graph manifest or auxiliary service can be developed outside the basic Transparency Service registration path. Third, statements about statements are useful for build failures, fixes, revocations, audit results, and "latest statement" questions. The relation vocabulary should support this pattern without forcing every payload to use the same schema. Fourth, hardware and cloud examples should be used carefully. They motivate the generic binding model, but they do not turn this draft into a hardware or cloud assurance specification.

Acknowledgments The author thanks the SCITT WG participants for discussions on opaque payloads, relationship metadata, graph building, and hardware supply-chain use cases. The SCITT and OCP case-study discussion helped sharpen the scope boundary between SCITT statements and domain-specific hardware claims.