SCITT 2024-07-25 2000Z-2130Z

Chairs: Christopher Inacio, Jon Geater
Area Director: Deb Cooley
Notetakers: A.J. Stein

0 Welcome and Introduction (5 mins)

• No requests to agenda bash.

5 SCITT Overview (10 mins)

• Steve Lasker presented overview of SCITT key concepts, work state,
  and relevant I-Ds.
• No time for Q&A, moved onto next presentation.

15 Recap since 119 (10 mins)

• Henk Birkholz and Roy Williams present progress on changes to I-Ds
  in the past months since IETF 119.
• Question for participants from COSE WG: is dependent I-D COSE Hash
  Envelope get adopted by WG? (Note from scribe: couldn't hear, people
  didn't talk on mic)

• Orie Steele: I think Justin pointed this out in COSE, if you are
  signing a hash then you better check the hash of the artifact. It's
  not opaque.

  • Henk agrees.
  • Roy that is valid but that is not the responsibility of the
    ledger.

• Brendan Moran: It seems that the URI being in the unprotected header
  is odd. What in the threat model declare this is ok or motivate this
  decision?

  • It's a threat vector general Internet for deployments for
    non-public system.

• Justin Richer: I should clarify a point germane to this discussion
  in COSE re a detached hash. Typically Merkle trees are not. The
  problem with that approach is that it is sitting there and doesn't
  map back to whatever it is pointing to, that's the risk. This is a
  data structure implementation/note concern. Not so familiar with
  this draft, don't know if it belongs in
  draft-ietf-scitt-architecture or another draft, but should be in
  security considerations of relevant I-D.

• Steve Lasker: location is a hint (it used to be call that)

  • Brendan Moran: what about forged URLs in an unprotect header?

• Orie Steele: you still need to match hash in signature, agreed with
  previous questions and impressions from others.

• Roy Williams

  • Some of this work will be addressed later today in SCITT
    architecture.
  • We don't want to duplicate all certificate chains in
    configuration; browsers typically have 300 different CA and
    roots of trust to maintain.

• Henk Birkholz: architecture is not done, profiling to be done and
  not germane into the specifics of this document (but others).

• Henk Birkholz: I want to address the PRs in the Hackathon primarily
  from Hannes Tschofenig. All but four were approved and contentious.
  Noteworthy open items:

  • Consolidating function names and role names

    • Verifier -> Relying Party (RP)
    • Issuer and RP -> now roles
    • Auditor is specialization of RP

  • Please raise issues, or they are done or will soon to be
    resolved

25 SCITT Architecture (20 mins)

• Progress towards the SW-SC use case
• No time for Q&A to keep on schedule.

45 SCRAPI (15 minutes)

• Jon Geater presents (chair hat off) on SCRAPI I-D updates.
• Roy Williams: the can of worms that Jon opened gets to a challenge
  to the basic functionality level it seems we need that will be
  different across verticals.

• AJ: we need something for matching identifiers to invariant
  definitions of an artifact that is pluggable in the API and that is
  outside of the scope of this WG.

  • Steve Lasker: concur, already pluggable in API, but not our
    problem.

• Jon Geater: constrain to issuer and subject for now (not other
  things for now).

  • Locating by hash is very practical, but we can add it back later
    if necessary given approach to above.
  • List of transparent statements, not other artifacts
    (understandbly controversial).

60 Hackathon Report (10 minutes)

• Steve Lasker presented on Hackathon work and outcomes.
• AJ Stein: should we reflect Orie Steele's Hackaton demo of
  CrowdStrike patch remediation as a more generalized use case in
  draft-ietf-scitt-use-cases?
  • Jon and Steve: yes, sure, it is more of a procedural question is
    we won't officially release it, but go ahead.
  • AJ to add issue.

70 Next Steps (5 minutes)

• Chris Inacio: see chairs if you have questions or interest in
  mailing list management. We have a call for secretary?
• Document progression
  • AJ Stein: Michael Richardson's review on list was very
    constructive, but there is a need to properly life conceptual
    elements of the use case, actually address protocol (and not
    through simply reorganizing sections), and properly document how
  • Deb Cooley recommends perhaps other early review calls (you have
    already done that with the HTTPDIR review)
  • WGLC poll on draft-ietf-scitt-artchite: (yes: 14; no: 14; no
    opinion: 15; total participants in MeetEcho: 68)
  • Hannes Tschofenig offers to do a SECDIR review
  • Henk Birkholz is an excellent tool to focus eyes on it (we are
    not clear we even want the use case abstracts in there)
  • Chris Inacio: the numbers speak for themselves
  • A.J. Stein: when people poll with that question, they typically
    ask first if people had read any version of the drafts at at all
    or the most recent versions.
  • Deb Cooley: you can have many WGLCs without limit, just do it,
    there is no harm. (Others concur.)
  • Chris Inacio asks for in-person

75 AOB Open Mic (10 minutes)

• A.J.: protocol and profiling gap issues, where will that happen if
  it is not in the architecture or use cases, where do we put that?
  What is the scope in the charter and how does this feedback into
  open milestones?
  • Henk: how do you profile a protocol? I do not understand how
    that works and what do you mean.
  • A.J.: there is a gap, call it profiling or something else, but
    how do bridge the necessary customizations at different
    implementations
  • Roy: interoperability we need to test at the COSE and CBOR
    level, that is where the interoperability occurs and others are
    out of scope in
  • Henk: now I understand what A.J. means better with his reply.
    Perhaps a guidance document in SCITT to glue the other docs
    would
  • Mike Prorock: we want to not do that in the current documents,
    and be careful with what we do do in scope, because we don't
    want to try to standardize too much and suffer the same problems
    that DID has in IETF in this area.
  • A.J. Stein: I agree with Mike, Roy, and Henk, I would greatly
    appreciate working on a guidance doc.
  • Deb Cooley: there is no guidance document in your charter, even
    though the charter is long with other milestones.

85 Wrap-up and Conclusion (5 minutes)

90 -- END --