Minutes IETF124: scitt: Tue 16:30
minutes-124-scitt-202511041630-00

SCITT IETF-124

Welcome and Administrivia - Chairs - 10

• Note takers
• Notewell
• Agenda bashing

Status of Adopted Documents - Authors - 15

• Henk Birkholtz is presenting
• WG - An Architecture for Trustworthy and Transparent Digital Supply
  Chain

• WG - SCITT Reference APIs

  • Comment from ISG: "Transparent statement" vs "Transparency
    statement"
    • not changing document

• Related draft - COSE Merkle Tree Proofs

• Related draft - COSE Hash Envelope
• SCRAPI v05 is in WGLC
• Transparent statement made about opaque payloads.
  • These are open questions coming to this WG.
  • Do they belong to SCITT or some other WG?

Receipt Profiles - Amaury Chamayou - 15

• Amaury is presenting remotely

• SCITT Archtecture uses COSE Receipts

  • Verifiable dtaa structure
  • Aimed for RFC9162
  • No known depoyed implementations...

• However, there are two deplyed COSE receipt implementations

  • Datarails Forestrie
  • Microsft SCITT CCF Ledger
  • There was an interop demo in IETF Madrid

• Merkle Mountain Range Profile

  • Efficient asynchronous accumulators
  • Always balanced

• CCF Profile

  • single root, unbalanced
  • Confidential Consortium Framework
  • Distributed system

• Next Steps

  • Adopt profiles in the SCITT WG
  • Implementors of verifiers would benefits from this work

• Does this work belong to this WG?

  • COSE WG?

• Orie Steele: The COSE registry were setup

  • Part of the motivation was for other WGs to use it
  • This work should probably remain in SCITT

• Who has read the CCF Profile?

  • About 5 people
  • Can these people post reviews on the mailing list?

• Discussions lead to this work belonging to SCITT

SCITT & OCP Case Study - Nobuo Aoki - 15

• Nubuo is presenting in person
• OPEN Compute Project (OCP)

• Sw/fw provenance with SCITT

  • Can be accomplished using SCITT architecture

• Case study: extension to hardware components

  • HBOM
  • the possibility has emerged that SCITT can go beyond firmware

• Points of controversy:

  • can SCITT include hardware

• Next actions

  • Exploring limits of SCITT
  • Find valuable use cases
  • Take time to answer these questions
    • Scope within SCITT charter?
    • Should charter be updated?
    • Should we seek assistance from other WGs?

• Henk:

  • Since payloads are opaque, how is the tree hierarchy represented
  • COSE header could be used to record meta-data about the payload
  • Some statement are not as opaque as others
  • To protect the supply chain, do we need to expand the charter?

• Orie:

  • Henk's comment on COSE headers:

    • Possible to encode graph information in header

  • SCRAPI does not provide API for working with graph info

    • If SCRAPI needs to deal with graph info, then it will be a
      much longer effort

• Amaury:

  • One issue is that there is no deterministic encoding

• Henk:

  • Possibility is to leave SCRAPI as is, and add more functions
    (auxiliary services) later for graph discovery.

• Chair:

  • This is a nice presentation (BOM and SBOM)
  • Good conversation about SCRAPI
  • But, what is the direction we are taking? Does it affect the
    charter?

• Orie:

  • the error was the initial assumption that SCITT was only about
    software.
  • The graph does not care about nature or artifact.

• Amaury:

  • There are already solutions for hardware, not necessarily
    compatible with SCITT
  • Should we try to unify the field?

• Chair:

  • We should take this discussion to the mailing list

Applying SCITT to FDA Labels - Dick Brooks - 15

• Jon is presenting remotely

• This is another use case discussion

  • Can we re-use SCITT for other purposes

• Medical device manufacturers must satisfy FDA guidelines

  • Need hardware and software BOMs
  • These artifacts can be easily shared via SCITT Trust Registry

• FDA Cybersecurity Label Requirements

  • Labelling referred to physical disclosure

  • Cybersecurity Transparency

    • Labeling recommendations for devices with cybersecurity
      risks

  • The risks change over time with device upgrades (dynamic)

    • Static labeling does not work

• Registering a Trusted Location (URL)

  • APIURL -> SCITT Registration Location
  • Keep the information updated while remaining transparent
  • Small form factor and supported using cryptography are nice
    properties

• MDM Registration of Cybersecurity Label URL

  • MDM = Medical Device Manufacturer
  • Consumer is ultimately a client of SCRAPI

• Is this use case in scope of WG?

• David:

  • Supports view presented
  • UK did not move forward with labeling
  • However, might be great for IOTs

• Jon:

  • Seems sensible
  • SCRAPI is in LC
  • Review to ensure this use case fits (need to keep as is or
    expand)

Slack/AOB - All - 20

• Henk:

  • I am assuming that we want more associations
  • Where do we put them (in COSE header, somewhere else)
  • Should we make a call?
  • We keep returning to the same question
  • chair: not sure how to phrase this question for a show of hand
    (Deb: take it to the list?)

• Orie:

  • General comment. If doing forensic work, the work is focused on
    payload (ignore SCITT)
  • RATS WG is fine building graphs with only the payload
  • Should SCITT offer another graph on top (in parallel)

• Yogesh:

  • The architecture is flexible and allows a layer to capture more
    information
  • Leave the other aspects to the payload

• Amaury:

  • Agree with Yogesh
  • Many semantics that may not be related
  • Exposing all the subtleties will be difficult

• Henk:

  • One can not capture all the semantic relationships
  • In the scope of software and hardware supply chain, there are
    probably relationships worth capturing
  • The experience in supply chain can probably be captured
  • Need to save the need to scrape the complete database
  • Need to experiment

• Jon:

  • In agreement with all the points; need to scope
  • Once a receipts is received, it can not be rescinded
    • For example: what is the latest SBOM?