SCITT IETF-124

Major items

Complete Minutes

Welcome and Administrivia - Chairs - 10

Note takers - Nicole Bates (thank you from the chairs)

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?