Supply Chain Integrity, Transparency, and Trust (SCITT)
bofreq-birkholz-supply-chain-integrity-transparency-and-trust-scitt-08

The information below is for an older version of this BOF request.
Document Type Proposed BOF request Snapshot
Title Supply Chain Integrity, Transparency, and Trust (SCITT)
Last updated 2022-05-26
State Proposed
Editor Henk Birkholz
Responsible leadership Roman Danyliw
Send notices to (None)
bofreq-birkholz-supply-chain-integrity-transparency-and-trust-scitt-08

BoF Name: Supply Chain Integrity, Transparency, and Trust (SCITT)

Background

Concerns about the security of supply chains, including those for physical goods, services, and digital products, have been around for a long time. This work aims to improve supply chain security by making the actions of entities in that supply chain transparent and thereby accountable. Statements made about supply chain elements, such as software and hardware components, must be identifiable, authentic, verifiable, and non-repudiable (enabling third-party verifiability, auditability, and long-term accountability).

SBOM is a use case that the IETF can focus on, as many of the specific skills are already well-represented among its experts. Inputs such as SPDX, CycloneDX, (Co)SWID can be important building blocks; this plurality of description technologies may be a lasting property of the ecosystem, but requires a common substrate of trustworthiness.

The SCITT discussion at the IETF 113 SECDISPATCH session yielded several topics as its output, of which some will be topics of this interim BoF. The primary output of this BoF is intended to be building blocks of preliminary decisions on how to scope an upcoming chartering effort.

The IETF has completed significant technologies that make the premise a solvable problem:

  • COSE
  • RATS
  • The SUIT architecture
  • SACM (CoSWID)

(Many other technologies such as TLS and the TLS application interface are potentially useful building blocks.)

Description

The scope of this BOF is focused on solutions that fulfill a set of fundamental guiding technical objectives: IoT-applicable, crypto-agile, and identity-agile.

The intent is to create a globally uniform/interoperable (counter-)signing format for "Statements made about supply chain elements", to enable offline/air-gap validation, and to reduce emerging issues with respect to claim-lifetime & identity-lifetime.

The planned results for the non-WG forming BOF include:

  • Expression of interest in solving the described problem through standardization in the IETF
  • Kick-off for discussing how to standardize illustrated supply chain security problems at the IETF
  • Minimal/conceptual charter building bloc

The activities to be spawned from this BOF should result in:

Success factors:

  • Establishing a shared understanding of the problem statement
  • Bringing relevant stakeholders into the room
  • Stimulating list/discussion activity

Required Details

  • Status: Non-WG-Forming BoF
  • Responsible AD: Roman Danyliw
  • BOF chairs: Hannes Tschofenig <hannes.tschofenig@arm.com>
  • BOF proponents:
  • Number of people expected to attend: 50
  • Length of session (1 or 2 hours): 2 hours
  • Conflicts (whole Areas and/or WGs): No conflicts as this is a virtual interim.
  • Chair Conflicts: No conflicts as this is a virtual interim.
  • Technology Overlap: COSE, RATS -> No conflicts as this is a virtual interim.
  • Key Participant Conflict: TBD

Information for IAB/IESG

  • Any protocols or practices that already exist in this space:
    • Notary/ORAS
    • Sigstore
    • SBOM
      • SPDX
      • CycloneDX
      • (Co)SWID
    • Endorsements
      • In-Toto
      • SLSA
    • IETF SBOM Access
    • COSE/RATS
  • Which (if any) modifications to existing protocols or practices are required: session output?
    • COSE Secure Receipt Representation (Read/Write)
    • Standardization of Claims/Endorsements
    • DiD backbone with extensions
    • Protocol extensions for Indexing (are there fundamental Indexing implementations, or is it per vendor so that things such as Rego can be used). This could mean that specific types of content are explicitly known, allowing for efficient consumer uses cases.
    • Audit Proofs
  • Which (if any) entirely new protocols or practices are required:
    • Interoperable envelope format, signing, and countersigning for a transparent claim.
    • Registration policies for inclusion in transparent logs.
    • Receipts for verifying inclusion in transparent logs, based, for example, on Merkle Trees.
  • Open source projects (if any) implementing this work:
  • Traceability Interoperability work at W3C Credentials Community Group

Proposed Agenda

Problem Statement (25 min)

What problem needs to be solved?

The traceability of physical and digital artifacts in supply chains is a long-standing but increasingly severe security concern. The problem to be solved is to define a generic and scalable architecture to enable transparency across any supply chain with minimum adoption barriers for producers and enough flexibility to allow different implementations of transparency services with diverse auditing and compliance requirements. The architecture should support the ongoing verification of goods and services where one may assure the authenticity of entities, evidence, policy, and artifacts, and where the actions of entities can be guaranteed to be authorized, non-repudiable, immutable, and auditable.

Is the timing right?

The end-to-end supply chain for a given good or service is highly complex due to globalization, third-party dependencies, varying customer requirements, legal and regulatory compliance, and many other factors. Supply chain complexity manifests quality, sustainability, reliability, safety, and security risks. Governments and companies worldwide have experienced numerous supply chain attacks by criminals targeting weaknesses in these complex supply chains. In response, global entities have initiated compliance mandates, developed novel solutions, or are still actively pursuing emergent technologies to reduce supply chain risks. The use cases presented below highlight the acute market signals driving the urgency to define globally interoperable supply chain transparency services.

How does it relate to other IETF work?

Core technologies from the IETF can act as building blocks in this area ranging from digital signing technologies to distributed identity efforts. The intention is to add to these technologies so that many of the additions are also building blocks that are applicable beyond the specific objectives of SCITT.

A Notional Complex Supply Chain

Stages within the supply chain are connected upstream and downstream and may include one-to-one, many-to-one, and one-to-many relationships through the lifecycle of the product. We assume that the suppliers, consumers, and/or standards bodies have defined the following:

  • Generalized process layout for the product output(s)
  • Process threat models
  • Mitigations and best practices
  • Artifacts recommended to mitigate threats and acceptable residual risks
  • Data storage and retention
  • Auditing and compliance requirements

For a complex supply chain, we consider four personas: the supplier, the consumer, the auditor, and the notary.

  • Supplier

    • Receives a production request
    • Inherits BOM(s) and product output(s) associated with the upstream processes
    • Creates a signed process layout based on supplier-specific implementation of standards and downstream requirements
      • Process steps
      • Required artifacts
      • Artifact metadata
      • Claims
      • Sublayout integration (upstream)
    • Sources required materials and tools, and verifies and records provenance
    • Executes process steps, sign and store artifacts, metadata, and claims in accordance with the process layout
      • Tags each product output with a unique identifier
      • Generates and signs a Bill of materials (BOM) for each product output
      • Submits signed content to the notary
    • Ships product output(s) to the next supplier(s) or consumer(s) in the supply chain
    • Applies continuous supply chain security monitoring to provide robust security analytics and actionable intelligence for product output(s), including updates and/or revocation as appropriate

  • Consumer

    • Receives finished product output(s) and BOMs associated with the upstream processes
    • Validates the:
      • Finished product output(s) have one or more endorsements from trusted auditors that are notarized
      • Absence of non-compliance endorsements and at least one compliance endorsement
    • Creates a signed layout for provisioning, deployment, operation, and end-of-life
      • Process steps
      • Required artifacts
      • Artifact metadata
      • Claims
      • Sublayout integration (upstream)
    • Executes process steps, signs and stores artifacts, metadata, and claims in accordance with the process layout throughout the lifecycle
      • Tags each product output with a unique identifier
      • Generates and signs a Bill of materials (BOM) for each product output
      • Submits signed content to the notary
    • Applies continuous supply chain security monitoring to provide robust security analytics and actionable intelligence in the deployed system

  • Auditor

    • Performs auditing at any time given a product output identifier and BOM, to:
      • Verify what is recorded by the notary and leverage additional audit trail data as needed
      • Go back to the supplier(s) to gather evidence captured during production
    • Establishes data sharing agreements, as necessary
    • Audits receipts, claims and replays ledger for supplier(s) based on audit scope
    • Confirms compliance against standards and customer requirements
    • Provides analytical insights as needed
    • Produces signed endorsements of compliance or non-compliance
    • Submits endorsements to the notary

  • Notary

    • Validates identity and countersigns content received from the supplier, consumer, or auditor
    • Stamps epoch marker and issues receipt

Use Cases (10 min)

Software Bill of Materials (SBOM)

The growing complexity of large software projects requires additional management of modularity and abstractions, and keeping track of their complete Trusted Computing Base (TCB) is becoming increasingly challenging. Each component may have its own set of dependencies and libraries. Some of these dependencies are binaries, which means their TCB depends on their source and their build environment (e.g., compilers, tool-chains). Further, potentially untrusted channels and repositories may distribute source and binary packages.

An SBOM coupled with globally interoperable transparency service instances allows software developers, packagers, distributors, auditors, and users to assure the authenticity of entities, evidence, policy, and artifacts and receive guarantees that the entities can be authorized, non-repudiable, immutable, and auditable. This approach facilitates moving the software supply chain from a largely invisible part of the cybersecurity landscape into a visible, transparent, accountable, and highly observable component across its lifecycle.

Other Use Case Candidates

To be discussed in the 60 min discussion slot.

Proposed Standardization Scope (25 min)

  • Overview of why there is need for this work (partially based on drafts content (that serve as a general motivator and elaborate on problem statement) and partially on existing solotions) (5 min)
  • state-of-the-art overview (brief to avoid getting lost in the details) (5min)
    • X.509 CA based certification validation works for situations where either the identity does not matter, or it is the current valid certificate.
    • Claim\Endorsement signing, signature formats
      • sigstore, COSE/JOSE, ...
    • transparency systems
      • CT, CONIKS, rekor, Google Oak, ...
    • identity
      • credentials vs identity, PKIX vs DID, ...
    • SBOM formats
      • SPDX, SWID, RIMs, SLSA, CycloneDX...
    • Authenticode (proprietary)
  • Specification to enable global supply chain - software and physical goods. (overview of the work done to date + areas that need future development) (5 min)
    • Signature formats and identifier formats that work both physical and software supply chains.
    • A vocabulary, mechanism, and data sets to help determine the legitimacy of organizations participating in global trade and the status of the products and materials described therein. A preliminary version (https://w3c-ccg.github.io/traceability-vocab/#abstract) for the physical supply chain goods has been incubated as part of W3C Credentials Community Group. Inputs are required from other parties to evolve these specifications. At IETF, we would continue and mature these standards and extend them to software chains as well.
    • Discovery and exchange mechanisms, particularly related to both physical and software supply chain use cases. A preliminary version (https://w3c-ccg.github.io/traceability-interop/) has been incubated as part of W3C Credentials Community Group. Inputs are required from other parties to evolve these specifications. At IETF, we would like to continue and mature these standards.
  • Motivation for standardization (5 min)
    • Harder to secure when there is no standardization. Full fidelity interoperability is desired across each market space, as it simplifies attempts by producers to hit as broad a space as possible.
  • Describe architectural aspects, if needed (5 min)
    • Need for a digital Notary system. One which can:
      • Limit fraud
      • Verify and record the identification of participants
      • Maintaining an audit journal fit for Legal discovery
      • Produce a notarial receipt for all documents
    • Programmatic Generic Auditing
    • Supply Chain Document Storage. End points where endorsements, SBOMs, etc. documents can be recorded, allowing for:
      • Nesting from product to product,
      • Place to retrieve them when the shipping product cannot (think IOT type devices)
    • Third-party Endorsements. Move to a system where others can generate endorsements of conformance. This is not RATS.
      • Demonstrate that this is more than a spec exercise.
      • What is not envisioned to be standardized

Discussion (60 min)

  • Is the IETF the right place to do this work?
  • Which organizations need to be involved/collaborated with?
  • What are the expected technical challenges?
  • Is there interest in implementing such specifications?
  • Is the technology likely to get deployed?
  • Is there enough interest in helping with the work (spec editing, reviewing, implementing, deploying)?