Skip to main content

Minutes IETF122: scitt: Thu 02:30
minutes-122-scitt-202503200230-00

Meeting Minutes Supply Chain Integrity, Transparency, and Trust (scitt) WG
Date and time 2025-03-20 02:30
Title Minutes IETF122: scitt: Thu 02:30
State Active
Other versions markdown
Last updated 2025-03-19

minutes-122-scitt-202503200230-00

Welcome and Introduction (5 mins)

SCITT Overview (10 mins)

  • Henk
  • Review Update Streams, supporting multiple vendors to submit
    statements about an artifact
    ## Recap since 121 (10 mins) {#recap-since-121-10-mins}

  • Steve

    • Architectural Overview. Nicer picture, no rotation required.
    • Technical recap: scrubbing and polishing the architecture
    • Cleanup on the SCRAPI draft, pushed merkle tree proof to ISEG
      for adoption

AJ Stein: The diagram has that we have 2 organizations doing a
transaction, but we don't have any text for that?
Steve: We've definitely talked about it, but it might not be in the
draft now; but it is supported,
Multiple parties could make statements about the same subject (e.g. a
software security company could make a statement about some other
entity's software) and the provider could then make a counter statement
saying something like "that issue is fixed"
AJ: Not that there is a problem in the model, per se, but that the text
says it is singular.
Steve: will check the text
Henk: It isn't explicit in the text, but it is there since the first
use case is software

Introduction to Transparency 201 (20 mins)

  • Jon
  • Not just a collection of misc information
  • Focused on quality statements, assuring statements can't be
    backdated
  • not defining a way to store statements, those are adjacent services.
  • as data is moved around, you can lose a lot of crucial contexts, and
    integrity protection
  • SCITT standards to detect changes of content as it's moved.
  • Verifiable record keeping
  • We want to identify the identities that are making claims. Focused
    on business use cases, not personal identities
  • Not just centralized registries, happy to support, but not the focus
  • Why isn't just publishing anything useful?
  • Just becuase you can see something, doesn't mean it's true
  • They should be treating them as witness statements, to judge whether
    you trust the identity making the statement
  • You can make an informed decision, based on who made a statement
    about a thing
  • Scenarios

    • Tamper proofing - more versatile than just a signature
    • Pre-commitment - why we have merkle trees, not just a signature.
      Capture a photo of my cat. Then, when it's stolen, you can say I
      recorded a picture of my cat a month ago, so i can prove it's
      mine.
    • Even if you delete your copy, if someone else has a copy, they
      can still validate the integrity of the copy
  • Non-equivicoation

    • What stops me from pictures of 500 cats, then claiming I owned
      them all
    • The transparency service would show that you've created 500
      entries, and not just the realistic few
  • Building Blocks

    • Not all parts may be required to every instance

Erum Welling: Does the provenance contain the historical ownership?
Jon: Partially, it does capture some of it, but it depends on some
external searching ability; you have to be build to capture the subject
name and then find it
Erum: If the artifact gets modified, what happens?
Jon: SCITT only provides this signing and transparency; it is avowedly
agnostic to the content of the artifact; so it is possible to link
things together with their subjects and statements, but its not inherint
in SCITT.

SCRAPI and SCITT Transparency Services!

  • Steve

    • What is stored on the append only log

      1. Signed statetment
      2. Hash
      3. Both (yes)
    • Layering the SCITT architecture
      Architecture

      • Transparency Service Implementation
      • SCITT append only log
      • SCITT registrationtion
      • AAPI for Ancillary Services
    • Choices around where meta data goes, what's protected and
      unprotected

    • Now that we get the receipt back, we can put in the unprotected
      bucket
    • MCR: don't forget you can use redirection by saving a key that
      redirects

mcr: feeling on the fence about the unprotected header; selective
disclosure from teh SPICE mechanisms uses them potentially; it might
want behave differently. Might want a layer of indirection based on the
unprotected part. And the impacts of the subject from things that might
be the same, but have different unprotected material.
steve: we struggled with this, COSE says don't include the unprotected
header, and the receipt example is good with the expense report
mcr: e.g. capturing the exchange rate which is time dependent

aj: can you clarify what should and should not be stored in the
transparency log, you mentioned something about that quickly
steve: the ledger is only protecting of the signed statement, but an
implementation could include additional stores with the additional
information. So the unprotected header could be in the log, but it
doesn't have to be in the log
aj: so the draft does't use MUST on what you have to include and
exclude from the log
steve: there is a MUST that says you have to exclude the unprotected
header; want to make sure what is written to the log so that it can be
verified consistently
aj: okay - get what you're saying now

erum: is there a way for a chain to bypass this (so skipping a change in
the artifact)
jon: SCITT as defined is about making statements about artifacts; but
you can make policy around the use of the statements

roy: unsigned headers cannot prove a timeline of changes, etc.

henk: the arch says that its okay to send a set of stuff with a whole
pile of junk in the unprotected header; registration policies are
interesting because they could control the rules about notarized uses
and unprotected materials

SCRAPI (15 mins)

  • Jon
  • Minimal Reference API
  • Basicly registering signed statements, getting receipts back
  • Got a bunch of things working, starting with an artifact, put into a
    payload, hash it wish cose-hash-envelope, submit, get the receipt
    and attach to the unprotected header to create a transparent
    statement
  • MCR - really interesting icons, would like to see those understood
    and standardized

    • Bottom right is the inclusion proof
    • Request to put the svg's in the github
  • Jon

    • Reason for the multi-party iconography is they can be
      distributed
  • Henk

    • Can be transparent confidentiality
    • And confidential transparency
  • Jon

    • Transparency of the log information is completely separate to
      your policy of what's "public"
  • Implementations

    • DataTrails & Microsoft
      ## Hackathon Report (10 mins) {#hackathon-report-10-mins}
  • Jon

  • Nobuu Aoki and Jon hacked on code
  • Eliminated json and made all things cbor
  • Worked to remove cbor from the bodies, and use http for minimal code
  • Nobuo prototeyped YANG
  • Challenges between 121 and 122

    • Can't assume syncronous post/receipt
    • Have to deal with the id's, and may also fail before completing
    • Cleaver solution was to use resource moved placeholders
    • Might tell you a different location, based on sharding, success
      or failure
  • What we learned

    • the theory worked
    • better compat for retrofit implementations
  • Yang model for SBOMs

    • Two issues identified
    • How do I make the messy process of failed builds, show lineear?
    • If we can make statements about statements, we can resolve this
    • In SCRAPI, we have reliable locators, those can be used as
      pointers
  • Is there hearburn about making statements about statements

  • MCR

    • how is this YANG
    • Jon - focus on RFC 9472
  • A.J.

    • Can you explain how invaliate is implemented
    • Jon: 9472 says if you do a new version of a step, it's better
      than the old version
    • A.J. conceptual foundation is in 9042?
  • Henk

    • Once Steve's box of snakes are put back in, we can open a new
      box of snakes for statements about statements
  • Thanks to Auoki

Next Steps (5 mins)

  • Request if Architecture is ready for last call
  • Architecture to goto last call
  • AOB Open Mic (10 mins)

  • would you like to schedule a virtual interim in about 6 weeks to
    review the last call documents

  • Jon: If we get significant feedback, we can do that.
  • Chris: will look at what holiday's we'd need to navigate for a
  • Erum

    • Question about the use case documents.
  • Chris

    • IETF no longer publishes Use Case Documents as RFCs
    • Future use case documents can be done somewhere else
  • Henk

    • Can post new use caes documents
  • Chris

    • Some AD's don't like lots of docs that won't advance, and are
      asked to clean those out

Wrap-up and Conclusion (5 mins)