Markdown Version | Session Recording

Session Date/Time: 16 Jun 2022 16:00

SCITT

Summary

This non-working group forming Birds of a Feather (BoF) session for SCITT (Supply Chain Integrity, Transparency, and Trust) aimed to introduce a problem statement, an initial use case, and a proposed standardization scope for enhancing trust and transparency in digital supply chains, particularly for software. The session successfully gathered community interest and feedback, with a clear indication that a follow-up BoF for working group formation is warranted. Key discussions revolved around the need for verifiable claims, long-term accountability, and interoperable building blocks, while carefully defining what aspects are in and out of scope for IETF standardization.

Key Discussion Points

• Welcome and IETF Process Overview: Chairs welcomed new participants and reminded everyone of the IETF Notewell statement, emphasizing IPR and Code of Conduct policies. The session highlighted IETF traditions like "agenda bashing" and the principle of "rough consensus."
• BoF Context and Future Plans: Roman (Area Director) announced tentative IESG approval for a follow-up Working Group (WG) forming BoF at IETF 114 in Philadelphia. This indicates positive initial interest from the IESG, allowing the community to plan discussions across two meetings.
• Problem Statement (Yogesh)
  • Simplified Supply Chain Model: Illustrated a notional workflow from Producer A to Consumers B and C, highlighting the use of components.
  • Transparency and Trust: Introduced the concept of producers making claims about their products, which are then signed, validated by a notary, and stored in a transparent registry. This allows subsequent consumers and auditors to verify claims.
  • Industry Challenges:
    • Producers: Lack of a consistent, uniform, and homogeneous way to gather and share compliance evidence across diverse cloud environments and formats.
    • Consumers: Inability to verify product compliance, safety, security, quality, or sustainability. Lack of mechanisms for post-deployment vulnerability checks and reporting.
    • Auditors: No standard methods for auditing claims and ensuring compliance across varied solutions.
  • Key Definitions: Clarified terms like "Claim" (description of artifact), "Issuer," "Registration Policy," "Notary" (validates issuer identity and claims), "Transparent Registry" (consistent, append-only, cryptographically verifiable data store), and "Receipt" (verifiable proof of claim submission).
  • Motivation: Transparency provides accountability for bad actors, enabling rapid detection and remedial action even if malicious acts aren't prevented.
  • Pain Points: Inconsistent methodology for identifying/attributing issuers, notarizing claims, and linking actors to products, exacerbated by multiple data sharing platforms.
  • Draft Problem Statement: The increase in supply chain digitalization, complexity, size, and scale renders traditional auditing insufficient. A lack of standards for attributing supply chain data, generating claims, and aligning transparent data stores aggravates the problem. The proposal aims for simple building blocks guaranteeing long-term accountability and interoperability of software components across regions and organizations.
• Initial Use Case (Kate)
  • Software Supply Chain Focus: Emphasized the extreme complexity, dynamism, and high velocity (especially with open source) of software supply chains, making manual tracking impossible.
  • Trust and Risk Assessment: Highlighted the need for transparency in contributors and composition, and a common language for systemic risk assessment (replacing intuitive trust).
  • S-BOMs as Building Blocks: Acknowledged existing Software Bill of Materials (S-BOM) formats (like SPDX) but noted the lack of standards for sharing these documents and linking them over time.
  • Government/Industry Mandates: Noted increasing mandates for S-BOMs, driving the need for better solutions for chain of custody and identity.
  • Requirements: Producer statements must be identifiable, authentic, and traceable (e.g., for updates). Auditing provenance and linking claims/proofs at scale is crucial for operationalization.
  • S-BOM Life Cycle: Illustrated S-BOMs at various stages (source, build, deployed), noting different content and the need for traceability (especially for safety-critical systems).
  • Vulnerability Management: Described the iterative process of product releases, vulnerability disclosures, patches, and the need to track these with new S-BOMs for effective remediation and minimizing false positives.
  • Clarifying Question (John G.): Asked about "legally meaningful evidence trails." Kate clarified it needs to meet standards of proof for risk, moving towards "forensically ready" information with cryptographic verification of S-BOMs.
• Proposed Standardization Scope (Hank)
  • Narrowed Focus: Acknowledged the broad "all supply chains" problem and narrowed the focus to the "software life cycle problem."
  • In Scope Items:
    1. Supply Chain Entity Identification: Common, verifiable, long-term (indefinite period, >2 years) method to identify issuers of artifacts.
    2. Supply Chain Claims: Interoperable, homogeneous, authentic, and simple statements about artifacts, signed and made transparent.
    3. Claim Storage Qualities: Standardization of requirements for append-only, cryptographically verifiable, long-term accountable stores that can prove "statements made" and "statements read."
    4. Receipts: Standardized format for validated, offline-verifiable proof of writing to/reading from a transparency service.
    5. Auditor Capabilities: Enabling entities to trace all claims made over time.
    6. Controlled Transparency: Enabling choice for who can access/read claims (public to confidential) while remaining scalable.
  • Out of Scope Items (Initial Proposal):
    1. Storage Implementation Details: Exact storage component, query language, specific protocols for obtaining read/write proofs. This is a pragmatic decision to focus on core building blocks.
    2. Policy/Compliance: Defining specific access control policies or compliance rules.
    3. Reinventing Wheels: Explicitly stated intent to reuse existing IETF (e.g., COSE, RATS) and other technologies (e.g., Certificate Transparency lessons learned). Not redoing S-BOM formats.
  • Clarifying Questions:
    • Roadmap vs. Scope (Kate W.): Suggested viewing "out of scope" items as a roadmap for future work once the core is established. Hank confirmed this aligns with IETF's approach for initial charters.
    • Query/Retrieval Interoperability (Ori S.): Expressed concern about interoperability without defining query/retrieval interfaces. Hank clarified IETF focuses on message formats, not full APIs, but HTTP-based APIs could be considered for core functionality.
• Open Discussion
  • API Standardization (Michael P.): Strong desire for standardizing restful APIs for storage and retrieval to ensure interoperability and enable test suites. Proponents agreed this is important for adoption and avoiding divergent implementations.
  • Append-Only Log as Essential (Christopher W.): Questioned if the append-only, immutable log (transparent registry) is a necessary requirement for all use cases, citing operational complexity (e.g., Certificate Transparency logs). Sylvain Klepsch (Microsoft Research) argued it's critical for independently verifiable receipts and tamper-proof guarantees, enabling offline validation, but acknowledged openness to alternatives if they meet security properties.
  • DID Mandate (Christopher W.): Questioned the mandate for Decentralized Identifiers (DIDs) as the fundamental identity type, noting IETF typically punts on identity. Sylvain Klepsch clarified DID is used as a layer of indirection to identity systems, not mandating a specific method, allowing innovation in DID methods.
  • Implementer Interest (Christopher W.): Asked about concrete interest in building/experimenting with this technology given its scope. Sylvain Klepsch confirmed Microsoft Research's significant investment, full-time headcount, and intent to open source implementations, emphasizing the need for multiple, interoperable solutions. Other efforts like SPoT and D-BOM were mentioned.
  • Notary Role & Identity (Ned S.): Asked for clarification on the "notary" role, distinguishing it from DID's identity mechanisms, and the need for new receipt definitions. Kate clarified the need for long-term (10-15 year) identity tracking for entities (companies, projects) beyond an individual's key lifecycle, and how to represent historical trust (like a human notary). This extends to revocation/compromise and fiduciary responsibilities.
  • End-to-End Solution vs. Building Blocks (Roman): Questioned if the goal is an end-to-end solution or building blocks, and the demarcation of guarantees. Sylvain Klepsch clarified the focus is on interoperable building blocks that enable various solutions (e.g., Microsoft's own open-sourced solution). The scope aims for cryptographic verifiability, independently verifiable receipts, and an ultimate vision incorporating hardware attestation for automated, human-out-of-loop solutions. Antoine also emphasized defining technical properties for interoperability, like transparency and equivocation prevention.
  • Access Control (Elliot): Questioned if the standard needs to define identity forms for access control to logs, given products travel long supply chains. Antoine and Yogesh discussed that verifiability is possible without full ledger access (via Merkle proofs), making access control a policy decision for transparency service operators.
  • Problem Statement Clarity Poll: A poll was taken asking if the problem statement was clear. 77 participants voted yes, and 1 voted no, indicating broad understanding.
  • Interest in Working on Problem Poll: A subsequent poll asked if participants were interested in working on the problem. Approximately 20 participants indicated interest, showing a viable community.
  • "Claim" Terminology: Acknowledged the term "claim" is overloaded, causing confusion. Hank clarified that in this context, a "claim" is a statement about a supply chain artifact, signed and made transparent via the service, resulting in a "transparent claim."
• Mailing List Activity: Chairs emphasized the importance of continued discussion on the mailing list (scitt@ietf.org) to refine the problem statement, scope, and potential charter. Lack of mailing list activity would signal a lack of interest to the Area Director.

Decisions and Action Items

• Decision: A follow-up Working Group (WG) forming Birds of a Feather (BoF) session has been tentatively approved for IETF 114 in Philadelphia.
• Action Item: The community is encouraged to continue discussions on the scitt@ietf.org mailing list to:
  • Refine the problem statement.
  • Further define the scope of standardization, including what specific documents or specifications would be produced by a WG.
  • Address the questions raised during the BoF to prepare for a WG charter discussion at IETF 114.

Next Steps

• Mailing List Engagement: Active participation on the scitt@ietf.org mailing list is critical to mature the ideas and build consensus.
• IETF 114 WG-Forming BoF: Preparation will focus on developing a specific, actionable charter that defines milestones and deliverables, taking into account the feedback received during this session.