]> The Graduate University for Advanced Studies (SOKENDAI)

Japan n_aoki@ieee.org

SEC Supply Chain Integrity, Transparency, and Trust Working Group SCITT verification composite evidence statement graph supply chain audit This document defines a common model for composite verification of SCITT statement graphs. A composite verifier checks a set of SCITT Signed Statements, receipts, object bindings, and relationship edges under a named verification profile. The result is a structured report that can say which statements passed, which evidence is missing, which evidence is stale, and which statements conflict. The model is intended for verifiers, auditors, deployment controllers, update services, and other relying-party tools. It is not a new Transparency Service requirement. It does not define a universal supply-chain policy language and does not define the payload format of any statement type. 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 lets a consumer verify that a signed statement was registered in a Transparency Service. Many real decisions need a larger evidence set. A consumer may need to check that a firmware SBOM describes the firmware measured on a device, that an update authorization covers that firmware, that an attestation result was issued by an acceptable verifier, and that no accepted statement revokes or conflicts with the set. Without a common composite verification model, each ecosystem defines its own API, result terms, freshness checks, conflict handling, and evidence bundle format. This can lead to tools that cannot work together even when the individual SCITT statements and receipts are valid. This document defines an information model and an optional HTTP binding for composite verification. The model is intentionally small. It provides common request and result fields while leaving domain policy to profiles. The composite verifier can be local software, a remote service, an auditor tool, a deployment controller, or a supply-chain risk engine. It does not have to be the same component as the SCITT Transparency Service.

Working Group Context This draft is based on the observation that SCITT can register many statements about the same subject, but the basic registration path is not a full graph query system. IETF 122 discussion noted support for multiple vendors or organizations making statements about an artifact, and also raised the pattern of "statements about statements". The same discussion noted that reliable locators can be used as pointers. IETF 124 discussion raised the question of whether graph information belongs in payloads, COSE headers, or later auxiliary services. It also noted that SCRAPI does not currently provide an API for graph work, and that adding such support directly to SCRAPI would be a larger effort. This draft therefore treats composite verification as a verifier or auditor function. It can use SCITT statements, receipts, locators, and graph manifests, but it does not require the Transparency Service to make composite decisions.

Design Goals The goals of this profile are to:

• allow a requester to identify the subject of verification;
• allow evidence to be provided by value, by reference, or by graph manifest;
• allow the requester or profile to name required statement types;
• express issuer, relationship, freshness, and conflict constraints;
• return clear result values for pass, fail, warning, unknown, missing, stale, and conflict cases;
• support online and offline verification;
• allow evidence bundles to move between tools; and
• avoid defining the truth conditions of domain-specific payloads.

Non-Goals This profile does not:

• define a universal policy language;
• require a Transparency Service to perform composite verification;
• require the SCITT Reference API to support graph discovery;
• require a verifier to fetch all evidence automatically;
• decide whether a payload claim is true;
• define SBOM, HBOM, CBOM, VEX, attestation, vulnerability, or audit schemas;
• define best practices for software, hardware, cloud, or IoT supply-chain design; or
• replace SCITT statement and receipt verification.

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 imports the terms Protected Object, Statement Reference, Receipt Reference, Relationship Edge, and Statement Graph from .

Composite Verification:

The evaluation of several SCITT statements, receipts, object bindings, and relationship edges under a selected verification profile.

Verification Profile:

A named set of rules that tells a verifier which statement types, issuers, relations, freshness limits, and conflict rules apply.

Verification Request:

A request that identifies a subject, a verification profile, optional evidence, and optional constraints.

Verification Result:

A result object that reports the outcome of composite verification.

Evidence Bundle:

A portable package that contains statements, receipts, graph manifests, and policy identifiers needed for composite verification.

Result Code:

A short code that states the result for the whole verification or for one part of the evidence graph.

Why This Is Not a Transparency Service Requirement A Transparency Service should be able to stay small. Its core job is to accept a signed statement under a registration policy and return a receipt. Composite verification is different. It applies a relying-party policy to a graph of evidence. For this reason, a conforming Transparency Service is not required to implement the interface in this document. Deployments can implement composite verification in one of the following places:

• a local verifier;
• a remote verification service;
• an auditor tool;
• a deployment controller;
• an update service;
• a compliance system; or
• an auxiliary service next to SCRAPI.

This split keeps the SCITT registration path simple while still allowing ecosystems to exchange and verify graph-level evidence.

Verification Model Composite verification runs over a Statement Graph. The graph can be supplied in a Statement Graph Manifest, as separate references, or through another profile-defined package. A verifier performs four kinds of checks:

1. Statement checks: signature, syntax, profile, and optional payload checks.
2. Receipt checks: receipt profile, inclusion proof, and registration data.
3. Graph checks: object binding, required relationships, conflicts, supersession, revocation, and dependency edges.
4. Policy checks: issuer rules, freshness rules, required statement types, and domain-specific acceptance rules.

The verifier MUST verify all individual statements and receipts required by the selected profile before it returns pass for the whole graph. A verifier MUST NOT claim that a payload is true only because it is signed and registered. A registered false statement can still be false. Composite verification only reports that the evidence set satisfies the selected verification profile.

Statements about Statements in Composite Verification Composite verification can use statements that refer to other statements. This is needed when the evidence set has history. Examples include:

• an audit statement about a submitted statement;
• a fix statement that answers a vulnerability statement;
• a supersession statement that marks a newer SBOM as current;
• a revocation statement;
• a failed-build statement that records why a build chain did not complete; and
• a graph manifest statement that records a selected evidence set.

A verifier MUST treat these as ordinary SCITT statements. It MUST verify their signatures and receipts before using them. It MUST also apply policy to decide whether the issuer is allowed to assert the relation.

Verification Request A Verification Request identifies the subject and the verification profile. A request MAY include evidence directly or by reference. [+ tstr]}, ? freshness: {+ tstr => duration}, ? relationship_requirements: [+ relationship-requirement], ? conflict_policy: conflict-policy, ? result_options: result-options, ? nonce: bytes, ? request_id: tstr } node-reference = tstr / { ? object: any, ? statement: any, ? id: tstr } evidence-input = { ? statements: [+ any], ? receipts: [+ any], ? graph_manifest: any, ? embedded_bundle: evidence-bundle, ? evidence_locations: [+ tstr] } relationship-requirement = { from_type: tstr, relation: tstr, to_type: tstr, ? required: bool } conflict-policy = "fail" / "warn" / "ignore" / tstr result-options = { ? include_graph: bool, ? include_statement_results: bool, ? include_receipt_results: bool, ? include_missing_evidence: bool, ? include_conflicts: bool, ? include_warnings: bool } duration = tstr ]]> The verification_profile field names the policy family to apply. A profile can be general, such as scitt-basic-graph/v1, or domain specific, such as iot-device-runtime-integrity/v1. The accepted_issuers field is a constraint supplied by the requester or by a higher-level profile. This document does not define a global list of trusted issuers. The freshness field contains duration strings. TODO: decide whether this document should normatively use an existing duration syntax or define a small CBOR-native form.

Evidence Completeness and Discovery Composite verification cannot assume that the submitted evidence set is complete. A presenter may omit a conflicting statement, an old revocation, or a newer superseding statement. A verifier therefore needs a policy for evidence coverage. A verification profile SHOULD state at least:

• which statement types are required;
• which issuers or issuer roles are accepted for each type;
• whether the verifier must search for newer or conflicting statements;
• which locators or auxiliary services may be used for discovery;
• how old evidence may be before it becomes stale; and
• how to report a result when the verifier cannot check completeness.

When a verifier cannot check completeness, it SHOULD return unknown or warning instead of pass, unless the selected profile allows closed-world verification over the supplied bundle.

Evidence Bundle An Evidence Bundle packages the evidence needed for offline or asynchronous verification. any} } digest = { alg: tstr, value: bytes } ]]> A bundle can be used when the verifier cannot reach the original Transparency Service during evaluation. A verifier using a bundle MUST still verify the statements and receipts inside the bundle.

Verification Result A Verification Result reports the outcome of the composite check. any} } result-code = "pass" / "fail" / "warning" / "unknown" / "missing" / "stale" / "conflict" / "not-applicable" / tstr statement-result = { statement: any, result: result-code, ? issuer: tstr, ? statement_type: tstr, ? errors: [+ tstr], ? warnings: [+ tstr] } receipt-result = { receipt: any, result: result-code, ? errors: [+ tstr], ? warnings: [+ tstr] } missing-evidence = { evidence_type: tstr, ? relation: tstr, ? expected_issuer_role: tstr, ? message: tstr } conflict-result = { conflict_type: tstr, nodes: [+ tstr], ? message: tstr } warning-result = { warning_type: tstr, ? node: tstr, ? message: tstr } ]]>

Result Code Semantics A verifier SHOULD use the following meanings:

pass:

The evidence satisfies the selected verification profile.

fail:

The evidence does not satisfy the selected verification profile.

warning:

The evidence satisfies mandatory checks, but the verifier found a condition that should be shown to the relying party.

unknown:

The verifier could not reach a decision. This can happen when evidence is unavailable or when a profile is not understood.

missing:

Required evidence is missing.

stale:

Evidence is older than the freshness rule allows.

conflict:

The graph contains statements or edges that conflict under the selected profile.

not-applicable:

A rule was not applicable to the subject or profile.

TODO: Decide whether these result codes should be registered with IANA.

Example: IoT Device Runtime Integrity The following example is illustrative only.

Optional HTTP Binding This document defines an optional HTTP binding for deployments that want a remote composite verifier. The binding is not a Transparency Service requirement. The response body is a verification-result. A server MAY also support JSON media types for debugging or deployment convenience:

• application/scitt-composite-verification-request+json
• application/scitt-composite-verification-result+json

TODO: Decide whether the HTTP binding belongs in this document, in a separate binding document, or only in examples.

Registration and Retrieval Timing Composite verification may be run long after the original statements were registered. It may also be run while some evidence is still pending. A profile should not assume that a POST to a Transparency Service always returns a final receipt synchronously. A verifier or auxiliary service can encounter:

• a statement reference with no receipt yet;
• a resource that has moved to a different locator;
• a failed registration;
• a sharded service that returns a different status location; or
• a bundle that was prepared before all related statements were available.

The result model in this document can represent these cases with unknown, missing, stale, warning, or a profile-defined result code.

Asynchronous Verification Some evidence sets can require network retrieval, large receipts, external policy checks, or manual audit review. A composite verifier MAY support an asynchronous mode. In asynchronous mode, the initial response can return a status resource. The final result MUST be the same verification-result structure used by the synchronous mode. TODO: Define status codes, retry handling, cancellation, and expiry rules if the WG decides to include asynchronous behavior.

Privacy Considerations Composite verification can reveal more information than single-statement verification because graph edges show relationships among devices, software, services, cloud tenants, suppliers, and auditors. A requester SHOULD provide only the evidence needed for the selected profile. A verifier SHOULD avoid returning more graph detail than the requester asked for. Profiles MAY use encrypted statements, salted identifiers, selective disclosure, or access-controlled evidence bundles. A verifier that stores requests or results can become a sensitive data store. Deployments SHOULD define retention and access-control rules.

Security Considerations Composite verification depends on the integrity of every required statement, receipt, and edge. Implementations MUST verify the relevant signatures and receipts before making a pass decision. Implementations MUST apply issuer authorization rules for each statement type and relation. Risks include:

• accepting a graph with missing evidence;
• accepting a stale attestation or vulnerability statement;
• accepting a relation asserted by an unauthorized issuer;
• hiding a conflicting statement;
• mixing evidence about two different objects;
• confusing statement freshness with object freshness;
• returning a pass result for an unsupported profile; and
• leaking sensitive graph information through result details.

TODO: Add detailed error priority rules. For example, invalid receipt should probably take precedence over freshness warnings, while unsupported policy may return unknown instead of fail.

IANA Considerations This document requests no IANA action yet. TODO: Consider IANA registrations for:

• composite verification request media types;
• composite verification result media types;
• evidence bundle media types;
• result code registry; and
• conflict type registry.

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

Design Notes for Future Revisions This revision treats composite verification as an auxiliary verifier function, not as an extension to the core Transparency Service. This follows the concern that adding graph discovery to the basic registry API could make that API much larger. The IETF 122 discussion is reflected in this draft in three ways. First, the model allows more than one organization to make statements about the same subject. Second, the model allows statements about statements, which can help when a later statement fixes, updates, audits, or explains an earlier statement. Third, the model allows evidence to be identified by stable locators, so that a verifier can build a graph without requiring the Transparency Service itself to become a graph database. The IETF 124 discussion is reflected by keeping graph discovery and composite verification outside the mandatory SCRAPI registration path. The draft leaves open whether future profiles place graph hints in payloads, protected metadata, separate graph manifests, or auxiliary services.

Acknowledgments The author thanks the SCITT WG participants for discussions on graph building, opaque payloads, receipt verification, and hardware and software evidence. The IETF 124 discussion was useful in separating the core registry function from possible auxiliary graph and verification services.