owned this note
owned this note
Published
Linked with GitHub
# BoF Name: Supply Chain Integrity, Transparency, and Trust (SCITT)
## Description
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 verification and auditing).
This virtual interim non-WG-forming BoF will reduce agenda stress and save cycles in the already compressed IETF hybrid-meeting agenda.
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 planned outputs include:
* Goals and non-goals for an initial charter based on [An Architecture for Trustworthy and Transparent Digital Supply Chains](https://datatracker.ietf.org/doc/html/draft-birkholz-scitt-architecture) and participant input
* Initial core terminology on the topics of: ledger, receipt, identity, revocation, basic operation, and trustworthiness
* Initial requirement sets, including: iot-applicable, crypto-agile, and identity-agile
* Minimal/conceptual charter building blocks
Goals to be discussed include:
* Globally uniform/interoperable (counter-)signing format for "Statements made about supply chain elements"
* Offline/air-gap validation
* Claim-lifetime & identity-lifetime
Success factors include:
* Establishing a shared understanding of the problem statement
* Bringing relevant stakeholders into the room
* Stimulating list/discussion activity
<!--
### Content Item
* The SecDispatch 113 results give us community consensus that the proposed scope is a "WG-sized body of work."
* The goal of the non-WG BoF:
* initial discussion on global uniform/interoperable (counter-)signing format
* in-scope statements (cherry-picking from architecture):
* "ledger", "basic operation", "identity", "revocation"
* IoT-applicable, offline/air-gap validatable, crypto-agile
* Early Results of Community (Report): Summary & minutes
* Success factors/results
* minimal/conceptual charter building blocks
* establish a shared understanding of the problem statement
* increase list activity/participation
* bringing relevant stakeholders into the room
Replace this with a few paragraphs describing the BOF request. Fill in the details below. Keep items in the order that they appear here.
-->
## Required Details
* Status: Non-WG-Forming BOF
* Responsible AD: Roman Danyliw
* BOF chairs: TBD
* BOF proponents:
* Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
* Orie Steele <orie@transmute.industries>
* Jun Takei <jun.takei@intel.com>
* Hannes Tschofenig <hannes.tschofenig@arm.com>
* Roy Williams <roywill@microsoft.com>
<!--
* Get key supply chain stakeholder to the meeting
- Shopify?
- Intel
- SBOM group
- US Customs and Border protection
-->
* 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
* Endorsements
* In-Toto
* SLSA
* IETF SBOM Access
* COSE
* 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 transparent claim.
* Registration policies for inclusion in transparent logs.
* Receipts for verifying inclusion in transparent logs (based e.g. on Merkle Trees)
* Open source projects (if any) implementing this work:
* Under Cloud Native Computing Foundation (CNCF) are both NotaryProject and ORAS
* Building blocks
* GlueCose
* go-cose
* .Net COSE
* Traceability Interoperability work at [W3C Credentials Community Group](https://www.w3.org/community/credentials/)
* [w3id.org/traceability](https://w3id.org/traceability)
* [w3id.org/traceability/interoperability](https://w3id.org/traceability/interoperability)
## Proposed Agenda
### Problem Statement (10 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 in a way 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 transparent, accountable, and highly observable component across its lifecycle.
#### Safe Movement of Physical Goods Across Geographical Borders
Current customs entry processes and environment results in limited supply chain data visibility, and fragmented or lacking data submissions create an information gap. This creates a risk for goods entering the geographical borders. In addition, restricted usage of trusted data inhibits the collaboration between trade and partnering government agencies to validate and speed the entry clearance and targeting process, resulting in congestion in the supply chain processes, inefficiencies prior to entry of goods within geographical borders, delays in the abilities of regulatory bodies ability to apply appropriate custom releases and ability of regulatory bodies (e.g., U.S. Customs and Border Protection [CBP]) to apply timely consequences creating business risk for importers.
The use of technical standards which have been vetted through standards organizations like GS1 and W3C (in particular verified credentials and decentralized identifiers) allow regulatory bodies to understand clearly:
* **Who** is in control of the products being shipped
* **What** are the contents of a particular shipment
* **Where** are the parties associated with the shipment located
Understanding the *who*, *what*, and *where* about the goods entering and leaving the geographical borders help the regulatory bodies to:
* Gather critical supply and trade data without divulging proprietary information
* Receive data at the creation of the data from the original source
* Retrieve missing data for better quality information for earlier decisions regarding the shipments
* Improve data quality to make informed decisions about a shipment
* Assert verifications of the parties involved with a shipment
#### Securing Software Supply Chains
Software supply chain attacks are becoming more prevalent. Such attacks happen when a cyber threat actor infiltrates a software vendor’s network and employs malicious code to compromise the software before the vendor sends it to their customers. The compromised software then compromises the customer’s data or system. These types of attacks affect all users of the compromised software and can have widespread consequences for government, critical infrastructure, and private sector software customers, often resulting in crippling companies and bringing global operations to a halt. The software supply chain is becoming so critical that in May 2021, the president of the United States issued an Executive Order targeted at improving the nation’s cybersecurity.
The use of verified credentials and decentralized identifiers provides the necessary technical infrastructure to address critical software supply chain issues. Decentralized identifiers define a standard way to discover keys for issuers and subjects. Verified credentials define a standard way to discover semantics for private claims. These attributes of decentralized identifiers and verified credentials enable defense against powerful threat actors.
#### Confidential Computing
Confidential Computing can leverage hardware-protected trusted execution environments (TEEs) to operate cloud services that protect the confidentiality of data that they process. It relies on remote attestation, which allows the service to prove to remote users what is the hash of its software, as measured and signed by the hardware.
For instance, consider a speech recognition service that implements machine learning inference using a deep neural network model. The operator of the service wants to prove to its users that the service preserves the user's privacy, that is, the submitted recordings can only be used to detect voice commands but no other purpose (such as storing the recordings or detecting mentions of brand names for advertisement purposes). When the user connects to the TEE implementing the service, the TEE presents attestation evidence that includes a hardware certificate and a software measurement for their task; the user verifies this evidence before sending its recording.
But how can users verify the software measurement for their task? And how can operators update their service (e.g., to mitigate security vulnerabilities, to improve accuracy) without first convincing all users to update the measurements they trust?
A supply chain that maintains a transparent record of the successive software releases for machine-learning models and runtimes, recording both their software measurements and their provenance (e.g., source code, build reports, audit reports) can provide users with the information they need to authorize these tasks, while holding the service operator accountable for the software they release for them.
#### Microelectronics
The structures of microelectronics include composite features across numerous elements (e.g., hardware, firmware, software), each with unique lifecycle stages. The decentralized and generally proprietary supplier records contain diverse data sources. Supply chain insights and lifecycle data transparency for upstream processes are opaque when one assembles components to form a system or system of systems. Ultimately, the end customer must conduct a cybersecurity risk analysis and determine the boundaries of where to apply blind trust, typically driven by the lack of understanding at some level in the system.
The market requires an automated and cloud-scale supply chain security service to address the full-stack analysis of microelectronic systems at any moment throughout the lifecycle while maintaining supplier protection of intellectual property. A proposed solution is to apply a Zero-Trust philosophy using transparency services to support data-driven, quantitative risk assessments and management techniques to assure microelectronics meet confidentiality and integrity requirements and inform the end customer of residual risks.
#### Digital Product Passport
A circular economy aids in reducing waste by keeping products or their components in the loop through reuse, repair, refurbishment, and recycling. As a first step, many products which have reached end-of-life are now being remanufactured or recycled. Unfortunately, product data such as identification, technical records, lifecycle, materials, and hazards are often unknown or not shared by the industrial manufacturers. Customers lack data on a product's environmental footprint and recyclability, and manufacturers lack insights on how their products are reused or recycled through their lifecycle. A digital product passport, supported by transparency services, allows traceability of supply chain artifacts, auditable claims and compliance, and measurement and management of lifecycle data to promote a sustainable circular economy.
### Proposed Standardization Scope (40 min)
* Overview of current architecture draft (10 min)
* State-of-the-art overview (brief to avoid getting lost in the details) (5 min)
* 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](https://www.w3.org/community/credentials/). 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 as they relate 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](https://www.w3.org/community/credentials/). 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 standarization. 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 (15 min)
* Need for a digitial 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
* Programatic Generic Auditing
* Supply Chain Document Storage. End points where endorsements, SBOMs, etc. documents can be recorded to, 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?
* W3C Verifiable Credentials WG (Orie to liason)
* W3C Decentralized Identifiers WG (Orie to liason)
* What are expected technical challenges?
* Is there interest in implementing the specifications?
* Is the technology likely to get deployed?
* Is there enough interest in helping with the work (spec editing, reviewing, implementing, deploying)?
## Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.
* [Mailing List](https://www.ietf.org/mailman/listinfo/scitt)
* Draft charter: TBD
* Relevant documents:
* [IETF#113 Secdispatch Meeting Slides](https://datatracker.ietf.org/meeting/113/materials/slides-113-secdispatch-trustworthy-digital-supply-chain-transparency-services-00)
* [IETF#113 Secdispatch Meeting Video](https://youtu.be/tHbIaQG_UFs?t=3051)
* [Countersigning COSE Envelopes in Transparency Services](https://datatracker.ietf.org/doc/html/draft-birkholz-scitt-receipts)
* [An Architecture for Trustworthy and Transparent Digital Supply Chains](https://datatracker.ietf.org/doc/html/draft-birkholz-scitt-architecture)
* [Community Meeting Minutes](https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg)
## Frequently Asked Questions (FAQ's)
List below is a set of questions:
1) Does the standard being proposed here apply to Hardware Supply Chain or Software Supply Chain or both?
2) Has the standard been proposed only specific to above (as in 1) or can it be applied to generic class of supply chain, for example: Supply of Inventory or Supply of Cement in the construction industry ?
3) Why do you think such a problem which is industry specific and which can also be solved in a proprietary way( specific to organisational needs) mandates a standard?
4) What role does the IETF play in this area?
5) The problem at hand is complex involving multiple steps, however IETF focusses standalone and individual problems and works towards closing them. How do you plan to align with IETF goals with the nature of the problem in hand ?
6) What is your plan for creating synergy across various existing solutions present in the industry today?
7) Is there sufficient flexibility in the standard to accommodate data transparency and privacy? Full transparency is practical for open-source software, while closed systems require intellectual property protection.
<!--
# Roman's feedback
* The SecDispatch 113 results gives us community consensus that the proposed scope is a "WG-sized body of work." I don't think we can read more into it.
* I see discussion on the SCITT list (https://mailarchive.ietf.org/arch/browse/scitt/) which is great. I saw a few emails about community meetings. What are the result of those? What do they inform about future IETF work?
* To the question of viability of interim BOFs, definitely. The IESG has returned to supporting with SECRET (https://datatracker.ietf.org/group/secret/about/) being the first one (before IETF 113).
* Can you give a sense of what's changed among the proponents/community to accelerate the previous working plan of a likely high-attendance F2F meeting in July to a virtual meeting?
* Since you're already thinking another BoF at IETF 114, can you explain the goal of the non-WG BoF. What would success look like?
* Please also submit an official request at https://datatracker.ietf.org/doc/bof-requests. Paul and I will use this as the basis of discussion with the rest of the IESG. Since this is out-of-cycle (interim), there is no formal schedule to hit beyond us likely covering it as a telechat (Thursdays).
# Ben's feedback on Receipts
* On first look this seems unobjectionable.
* The draft seems to list the registration policy for the Tree Algorithms
registry as "TBD"; I would advise a lenient policy like "Expert Review" or
"Specification Required" (maybe even "First Come, First Served"!) since the
purpose of the registry seems to be to avoid collisions rather than to
reliably avoid dupication of effort.
# Action Items
* Henk will ask Allen Friedmann to present
* Henk will talk to Intel (Ned and Jun) to ask them to take a stance here
* TBD has to summarize community meeting results
-->