Minutes IETF119: scitt: Thu 23:30
minutes-119-scitt-202403212330-00

Meeting Minutes Supply Chain Integrity, Transparency, and Trust (scitt) WG
Date and time 2024-03-21 23:30
Title Minutes IETF119: scitt: Thu 23:30
State Active
Other versions markdown
Last updated 2024-03-23

minutes-119-scitt-202403212330-00

Welcome and Introduction

  • A.J. Stein and Steve Lasker volunteered to take notes for this
    session
  • Roman ("AD Emeritus") signalled transition to new AD, Deb Cooley
  • Thanks to previous chair Hannes Tschofenig
  • Welcome to replacement chair, Chris Inacio

SCITT Overview

  • Review of charter scope

  • Discussion of key principles of SCITT architecture

    • Interoperability
    • Opaque artifacts
    • Inclusion into Transparency Service
    • Identities register artifacts, artifact content is not important
      to TS operation

  • Review of payload design

Document Status

Recap since 118

  • Henk
  • A lot of the changes reflect cleaning up teh spec
  • Receipts were pulled out to anothe spc
  • SCIIT Architecture profiles the Receipt
  • Receipts are returned asyncronously, to resolve large scale
    solutions
  • Cleaned up terminology, such as Consumer which can be consfusing in
    a Supply Chain.
  • Mike Prorock: Is verifier and relying parties aligned with NIST
    terminology?
  • Henk: no, it was defined within the scope of SCITT to avoid reused
    words and provide definitions in the terminolgy
  • Justin Richer: naming is hard. Doing the correct thing to qualify as
    used in this document. Which is what (I) told NIST and the W3C. Can
    never get away from these clashes. Encourage to use the defined
    names, but can define the term as used in other spaces.
  • Orie: feed and subject - the subject identifier is of the opinion of
    the issuer. It's chosen by the issuer. How do two issuers talk about
    the same identifier?
  • Justin: without comment on feed as a structure. Brought up in many
    different spaces. The idea that issuer and subject need to be
    paired. Not a unique problem to this space. (NIST 800-63c regarding
    issuer and subject.    )
  • Mike Prorock: believing its an application level thing. If it could
    be pulled out to a separate document
  • Henk: might pu in the use-case document, that we may not publish as
    a ID
  • A.J.: Is the use-case going to be published.
  • Henk: it's up to the authors
  • Chris/Chair: There's questions on the value of publishing use-case
    documents. But, you can extract parts of the use-case into
    subsequent documents. however, the community has questions about
    publishing use-case documents. However, referencing use-case
    documents will continue to exist as an expired document.
  • Orie: my understanding was to settle the architecture documents.

SCRAPI

  • Specification of sample API endpoints longstanding part of the
    charter
  • Not the only method for interaction with TS
  • Orie: if you are looking at the key discovery endpoints, they are
    optional, and they based on OAuth SD-JWT designs and not invented
    originally here, we are trying to follow pre-existing designs and
    practices from OAuth, SPICE, and others. We need more expertise on
    key discovery protocols, feedback welcome.
  • Jon and Orie: DIDs are deprecated now, no longer mandatory for SCITT
    TS implementation.
  • Henk: thanks to HTTPDIR for review of the draft. Important
    terminology and edits to document made as a result.

  • Reviewers:

    • A.J. Stein
    • Monty Wiseman
    • Thomas McCarthy-How
    • Roy Williams

  • Orie: test suites, we have some Python code for early SCITT arch
    components. It's drifted from arch spec. Considering test suite for
    SCRAPI for conformance testing and spec validation.

    • Chris: historically, once you advance on standards track, you do
      an interop, provide evidence of interop of multiple
      implementations, advance from proposed to full standards track.
      My tl;dr
    • Michael Richardson: that is correct, increasing commonality of
      publishing a 2nd information doc with test vectors in it. Likely
      makes more sense for TLS and key exchange protocols, but SCITT
      could do that with throwaway private keys.
    • Hannes: I've organized a few interop events, there is no process
      from the IETF point of view, but costs a lot in terms of time
      and resources.
    • Orie: we make cookbooks, like HKPE cookbook for JOSE
      workbook       (in chat)
    • Roman: you request AD perspective, I appear. AD preference will
      be flexible. You can publish RFCs with test vectors, that's ok.
      You can have interop events, also ok. Think about goals and
      outcome (where you want results), and AD guidance and process
      will flex for you.

  • Thomas McCarthy-Howe: works in VCON WG and sees similarities,
    tracking artifacts in conversations often for AI processing. I like
    this work.

Hackathon

  • Contributions from remote folks (Jon and A.J.)

  • Jon: SCRAPI

    • Keen to make sure SCRAPI does it's job well and quickly
    • Getting back to a position of solid good running code, proving
      the architecture is in good shape
    • Consistent with RFC3552, added security considerations

  • Remote Signing by Corey at DigiCert

    • Copied the datatrails scitt-action, adding remote signing
    • Focused on the properties set in the protected header.
    • Moved the x5chain to the unprotected header
    • Had started with DIDs, got a lot of "feedback", and removed it
      to use X.509
    • Moving to the unprotected header allowed the header to be
      stripped, and reduce the size of the protected headers
    • Sounds like moving it out of the protected header has support
    • Made some opinioated choices to the properties
    • Made the kid the digicert guid. Could likely remoe it as we have
      the thumbprint

    • Hannes:

      • The security model is: when the issuer creates statements,
        how does that get to digicert?

    • Corey: the scitt-action has integration with the REST API

    • The analog of the CI/CD pipeline can create a hash of the
      artifact and sign it.
    • Orie: why -16 for the protected headers in the example from
      this system in Hackaton? Let's talk offline and work to correct
      that.
    • Mike Prorock: agreed.
    • Steve Lasker: during the build or other workflows, you're
      testing the software and then you want to make an attestation at
      that time and want to provision identity but not leave it too
      easily available in the build environment
    • Orie: concurs with the impressions of others at the queue
    • Orie: apologizes for all of Jenkins

  • Exploration: election data use-case

    • Roman: excited about SCITT interest in different domains, but
      charter scopes us to software supply chain
    • Deb: as current AD, I'll say the same

Next Steps 30

AOB Open Mic

  • A.J.: There are emerging adjacent (non-IETF) efforts showing up
    (e.g. sunlight; litelog). Is there a way of
    comparing/contrasting/learning from these external things?
  • Orie: There are a number of technologies that have evolved for TS in
    other services. (Key Trans, Cert). There's a lot of OSS work that's
    directly mappable to COSE Receripts. It would be awesome to see
    compatibility with the receipt draft
  • If you're interested in doing interoperability with SCITT receipts,
    Orie is happy to chat about that mapping. Thank you to A.J. for
    mentioning the Open Source Community. Always happy to chat.

Wrap-up and Conclusion