-
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
-
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
-
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