SCITT at UETF 118

Agenda

• Welcome and Introduction (5 min): Chairs
• Why SCITT is COOL (5 mins): Henk Birkholz
• Recap since 117 (5 mins): Henk Birkholz
• Registration Policies (15 mins): Jon/Cedric
• API & Receipt Updates (15 mins): Orie Steele
• Hackathon Report (15 min): Jon
• Next Steps and WG operations for 119 (15 min): Chairs
• AOB Open Mic (20 min – BE CONCISE!): All
• Wrap-up and Conclusion (5 min): Chairs

Notes

• Recording: https://www.youtube.com/watch?v=zEGob4oqca4

• Chair Finish brief introduction.

• Why SCITT is COOL (5 mins): Henk Birkholz

  • Need authenticity over time: things change, key material gets
    lost, ...
  • Importance to maintain authenticity over time
  • CBOR usage introduction for SCITT, together with CDDL and COSE
  • issuer created statements are always opaqe, and stored in an
    append-only log, which can be queried and audited later
  • Applications interact with SCITT
  • A receipt, issued from the Transparency Service, as a result of
    registration, provides proof
  • Issuers sign statements, and the Transparency Service verifies
    the identity of the signed statment and notarizes them with a
    counter singnature if the signed statement is registered.

• Recap since 117 (5 mins): Henk Birkholz

  • Recap of the PRs since 117: weekly meeting about use cases and
    architecture document contents, hackathon preparation, new Feed
    definition...
  • Mike Jones: CWT Claims and headers finished last call
  • Use Case Working Group Last Call this week, please provide
    feedback via scitt@ietf.org
  • Orie, AJ and MCR have volunteered to read the Use Case docs

• Registration Policies (15 mins): Jon/Cedric

  • A simple set of rules to be evaluated by the Transparency
    Service to determine admissibility of a Statement

  • A small number of requirements

    • Payload agnostic to make it interoperable

  • Can't predict all use cases or payloads as it's up to the
    application layer as they develop

  • Stored data structure needs extensibility
  • General access control concerns: API, Anti-spamming and issuer
    must be authenticated and identifiable to submit/register a
    signed statement
  • SCITT enables entities (issuers) to make statements about things
    (artifacts)
  • The collection of statements are associated through a
    CTW_Claims.sub
  • The SCITT structures provide these primitives to facilitate
    interoperablility
  • Recent breaktrhoughs in the spec are specific to registration
    policies.
  • Cedric Fournet:

  • Recap of registration process, where an issuer signs a
    statement, submits to the transparency service, and a
    registration policy evaluates, using a registration policy

    • https://scitt-community.github.io/scitt-api-emulator/registration_policies.html

  • Registry policies are configurations

  • Configurations can be updated
  • The statement will have a registration policy (config) statement
    id that identifies which regisgration policy was enforced for
    this specific statement
  • Verifiers can validate the receipt, even if they can't connect
    to the Transparency Service
  • Several open questions
    • Terminology on registration and/or configuration
    • Application profiles?
    • Sequence of signed statements for configuration

• API & Receipt Updates (15 mins): Orie Steele

  • 2 parts: CBOR definition for statements and receipt, the
    transport aware API for these messages
  • transparent statement = signed statement with a receipt
  • Learning CDDL is super helpful at understanding COSE and SCITT
  • Recap of the CBOR & SCITT specific headers

• REST API

  • Roman: IETF does support APIs
  • Explination of Feeds, using an example of making soup - not to
    be confused with an SBOM documentation
  • Roman: while we're discussing soup, the scope of SCITT is
    currently using Software Supply Chain
  • Back to software and firmware - they're like soup
  • Dan Druta: catch 22 with the questions and answers - how can I
    create a template for what questions will be asked
  • Orie: a registration policy can specify the type of requirements
    that are needed to be registered
  • Discussion if the sub in the example should be LDevID or
    IDevID. These are examples of how an issuerer can specify
    whatever they'd like to group a collection of statements.
  • In a software supply chain domain, you may see specific
    artifactTypes, such as SPDX SBOM, Cyclone SBOMs, SLSA, VEX,
    Vendor Response Files, or an updated VEX as new information is
    learned

• Hackathon Report (15 min): Jon

  • Strong participation at the hackathon
  • Spec focused, with some code
  • A lot of focus on the registration policies, with a
    client/server type relationship
  • Intermixing of Config and Registration information, as both are
    needed to be known in relation to what was evaluated, or
    configured when the signed statement was registered. The receipt
    will indicate all configurations and registrations
  • Had explored specifying a registration configuration format.
  • We decided to make it a transparency service specific
    implementation.
  • Furthered work on federation

  • Furthered work on API access control

    • https://scitt-community.github.io/scitt-api-emulator/oidc.html

  • Proved out DID resolution and verification

  • RKVST implementation eliminated need for translation proxy 
  • Begun collecting illustrative examples to help know when the
    building blocks satisfy the use cases
  • Federation POC from John Andersen
    • Uses Activity Pub from W3C
    • Exmple at: https://asciinema.org/a/619517
    • Additional examples:
      • https://github.com/scitt-community/scitt-api-emulator
      • https://github.com/scitt-community/scitt-examples

• Next Steps and WG operations for 119 (15 min): Chairs

  • Suggestion that weekly meetings are too many
  • More important to work in the mailing list, with topics and PRs
  • Thank you to Hannes for his contributions over the last year as
    Chair

• AOB Open Mic (20 min – BE CONCISE!): All

  • Henk: The Countersigning COSE Envelopes will go away as we'll
    focus on Cometer. SCITT will frost over other specs
  • Timestamps are available within the CWT_Claims
  • Simon: Friedberger: what's missing is a mapping of the metadata
    to the use cases. There seems to be a contridiction as we speak
    to content being opaque.
  • Jon: The group wants to be careful to not re-discuss/document
    specific content types, like SPDX and CycloneDX
  • Orie: Involved in other use cases at IETF, including Post
    Quantum. SCITT uses COSE to enable the different types of
    algorythms.
  • Massimiliano Pala: Are you considering of problem for tracking
    crypto, such as software upgrades.
  • Steve: the new content types, such as PQ are great exmaples of
    SCITT being content type agnostic, to support all these new
    content types that issuers may want to express on artifacts
  • Manu Fontaine: suggest symetric signature and symetric
    cryptography to solve the integrity of the agent. The agent can
    use symetirc keys.
  • Daniel: Briefly mention w3c introducing a transparency log. It
    was brought up to build upon SCITT. Have a preliminary proposal
    in a WICU. Source Code Transparency - Hannes suggestion to share
    with the list
  • Ned Smith: question on whether the tomatoe is fresh
  • Orie: classic notary example, where the notary doesn't quantify
    the validity of the content. Rather the issuer valid. Do they
    have valid key material?
  • Cedric: it's not really the job of SCITT to verify "tomatoes".
  • Ned: compromise is the type of check they did, was put in the
    issuer claims (statement)
  • Chunchi: related to certificate transparency. There's a new
    model for more effecient merkle trees.

• Wrap-up and Conclusion (5 min): Chairs